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FOREWORD 


The Systems Technology Laboratory (STL) is a computational 
research facility located at the Goddard Space Plight Center 
of the National Aeronautics and Space Administration (NASA/ 
GSPC) . The STL was established in 1978 to conduct research 
in the area of flight dynamics systems development. The 
laboratory consists of a VAX-11/780 and a PDP-11/70 computer 
system, along with an image-processing device and some 
microprocessors. The operation of the Laboratory is managed 
by NASA/GSFC (Systems Development and Analysis Branch) and 
is supported by SYSTEX, Inc., Computer Sciences Corporation, 
and General Software Corporation. 

The main goal of the STL is to investiage all aspects of 
systems development of flight dynamics systems (software, 
firmware, and hardware) , with the intent of achieving system 
reliability v/hile reducing total system costs. The flight 
dynamics systems include the following; (1) attitude deter- 
mination and control, (2) orbit determination and control, 

(3) mission analysis, (4) software engineering, and (5) sys- 
tems engineering. The activities, findings, and recommenda- 
tions of the STL are recorded in the Systems Technology 
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ABSTRACT 


This document provides the information necessary to under- 
stand the Autonomous Attitude Determination System (AADS) . 

It describes AADS requirements, program structure, mathe- 
matical algorithms used, and gives information for AADS 
execution and system generation. The document also de- 
scribes all interfaces with the AADS simulator and other 
information necessary for system maintenance. A second 
volume of this document, containing the AADS module descrip- 
tions, will be produced in September 1982 under the document 
number CSC/SD-82/6032V2. 
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SECTION 1 - OVERVIEW 


1.1 INTRODUCTION 

1.1.1 PURPOSE 

Autonomous attitude determination onboard a spacecraft for 
the purpose of automatic science data annotation is one of 
the key objectives of the National Aeronautics and Space 
Adminstration (NASA) End-to-End Data System (NEEDS) . The 
Autonomous Attitude Determination System (AADS) described 
here is designed to use gyro and star tracker data to com- 
pute the spacecraft attitude. The system will perform 
autonomously for long periods of time with only minimal 
ground support. 

To demonstrate the feasibility on the ground of such a sys- 
tem, the attitude determination system must be developed 
along with a simulator that will provide all necessary input 
and will receive the computed attitude and associated system 
performance measures. AADS and the AADS simulator could 
then be used to search for an appropriate set of initial 
conditions for each type of mission (or for a variety of 
missions and mission scenarios) . 

A detailed AADS system description is presented in this 
document. A preliminary version of the document was pre- 
pared earlier (Reference 1) . That version has been updated 
by adding AADS design changes and by giving additional in- 
formation on system execution and system generation proce- 
dures. 

1.1.2 DOCUMENT ORGANIZATION AND USE 

This system description is designed to help users understand 
and maintain the system. The document is divided into five 
major sections. Section 1 provides an overview of the sys- 
tem and can be used to gain both a basic understanding of 
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the system and the rationale for choosing this particular 
design to implement the requirements. Section 2 summarizes 
the system requirements, the design constraints imposed due 
to the selection of hardware for developing and implementing 
AADS, and the requirements for the system software of the 
target microcomputer. Section 3 gives detailed input, out- 
put, processing overviews, and the baselines for all compon- 
ent processes that make up AADS. Section 4 contains the 
requirements for execution, and Section 5 provides the de- 
scriptions of basic algorithms used for state propagation 
and update. 

In addition, appendixes provide predevelopment timing and 
memory estimates prepared by the system designers, and other 
information that may be used for future enhancement of the 
system. This document is written with the assumption that 
readers are familiar with the basic concepts of real-time 
systems and multiprocessing event-driven operating systems. 

AADS interfaces with the user by means of the Ground Support 
Simulator (GSS) , which is a part of the AADS simulator (Ref- 
erences 2 and 3). The user selects commands and AADS proc- 
essing options that are displayed by GSS. GSS uplinks the 
information to AADS and reads AADS output transmitted to the 
ground. GSS then prepares AADS output for use by the opera- 
tor and the analyst and displays error messages transmitted 
by AADS. A description of GSS and the basic operation of 
AADS will appear in a user's guide to be written by the de- 
sign team (Reference 4) . 

The AADS user's guide is written for tne operator, whereas 
this document is intended for four primary users; 

1. System developers--This document is designed to as- 
sist system developers (who are usually responsible for im- 
plementing component processes) , in learning processing 
modes (multiple processes), in supporting testing, and in 





n 

u 



y 




n 

Li 




1-2 



training analysts and operators. This document is also use- 
ful in designing systems to support similar missions. 

2. Launch mission analyst--This document provides help 
to the launch mission analyst in understanding system re- 
quirements, in learning and refining processing modes, in 
reinforcing understanding of the system to support operator 
training, and in planning postlaunch operation. The analyst 
may also use the document as a guide in planning any system 
enhancements needed because of changes in mission require- 
ments or oversights. 

3. Postlaunch mission analyst--The postlaunch mission 
analyst, responsible for postlaunch analysis and software 
maintenance, can also use this document to reinforce under- 
standing of the system and as a guide in planning system en- 
hancements to streamline processing or to satisfy a change 
in mission requirements, 

4. Operator--This document is designed to reinforce 
understanding of the system by the operator who has software 
responsibility or is interested in software system design 
and development. 

New users should read the user's guide to understand the 
actual operation of AADS and then use the system description 
to acquire a deeper understanding of the system. 

Additional documentation for the system includes the AADS 
Software functional specifications, attitude textbook, tech- 
nical memorandums, and the technical manuals describing the 
VAX-11/780 computer, the Intel 8086 computer, and the system 
software. A comprehensive list of references is given at 
the end of this document. 

The attitude software functional specifications (Refer- 
ences 1, 2, 5, and 6), written by the analysis team, contain 
the analytical details necessary to understand the 
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algorithms and mission requirements. The attitude textbook 
(Reference 7) defines the basic terminology/ describes the 
sensor hardware, and provides references for further read- 
ing. Technical memorandums (Reference 8) describe new or 
modified algorithms and, in most cases, are included in the 
system description document. 

The system description document provides the digital command 
language (DCL) procedures used for system generation and 
execution on the VAX computer; however, performing system 
maintenance may require additional details that will be 
found in various technical manuals. In particular, the 
Intel FORTRAN manual (Reference 9) contains information 
about the source language, and the operating system manual 
(Reference 10) provides information about the new operating 
system being developed by Systex to implement AADS on the 
Intel microcomputer. 

General operation-specific information in this document in- 
cludes (1) processing overviews, (2) data flow diagrams, 

(3) illustrations of internal and external interfaces, 

(4) DCL procedures for system execution, (5) descriptions of 
processing options, and (6) error messages. 

Maintenance-specific information includes (1) illustrations 
of the relationships among system components (baseline dia- 
grams) , (2) illustrations of internal and external inter- 
faces, (3) formats for AADS input/output, (4) DCL procedures 
for system creation, (5) descriptions of processing options, 
and (6) error messages. 

The source code contains descriptions of subroutine and 
COMMON area components in the form of prolog and program de- 
sign language (PDL) comments. 
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1 . 2 SYSTEM REQUIREMENTS AND IMPLEMENTATION 


1.2.1 MAIN REQUIREMENTS 

The main requirements for AADS are as follows; 

• AADS will compute the spacecraft attitude to anno- 
tate science data onboard the spacecraft. 

• The AADS design will meet the requirements of 
NASA’s Multimission Modular Spacecraft (MMS) 
series. It will support types of spacecraft with 
attitudes that either vary smoothly in time 
(Landsat-D) , or are nearly inertially fixed (Solar 
Maximum Mission (SMM)). 

• AADS will determine spacecraft attitude with an 
accuracy of 30 arc seconds (3a) for each axis. 

• AADS will perform in a real-time mode and in an 
autonomous manner for a long period of time and 
will require only infrequent ground support. 

• AADS will accept commands and data from the ground 
and will transmit attitude results, update results, 
activity logs, error messages, and raw sensor data 

. to the ground. 

• AADS will be implemented as a portable modular unit 
on a microprocessor onboard the spacecraft. The 
microprocessor will have 256 kilobytes of memory 
and no peripheral devices where 1 kilobyte equals 
1024 bytes. AADS will be initially implemented on 
a VAX-11/780 computer to test feasibility. 

• AADS will use gyro and star tracker data. Gyro 
data are used to propagate attitude, and data from 
identified stars are used to update attitude using 
a linear optimal filter (Kalman filter) that is 
stable against roundoff errors. 
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• AADS will provide for contingencies and error 
handling. 

1.2.2 CHANGED AND NEW REQUIREMENTS 

• AADS will use the regular form of the Kalman filter 
for state update. The Joseph form of the Kalman 
filter will not be used because it may require more 
computer time and may not eliminate roundoff errors 
(see question AT012 in Appendix B) . 

• AADS will acquire attitude when the initial atti- 
tude estimate is in error by up to 2 degrees. In 
addition, AADS will automatically change the star 
identification procedure depending on the current 
attitude uncertainty. 

1.2.3 IMPLEMENTATION SCHEME 

The implementation scheme is as follows: 

1. Complete a detailed design of the input and output 
functions; use top-level design for the attitude 
determination function. 

2. Code a skeleton (shell) system consisting of input 
and output functions. Complete the detailed design 
of the attitude determination function. 

3. Implement the skeleton system on the VAX-11/780 
. computer and demonstrate the interface with the 

AADS simulator. Demonstrate scheduling logic in 
the executive. Complete code for the attitude de- 
termination function and detailed error handling. 

4. Test attitude computation by using real or simu- 
lated Landsat-D telemetry data. Check attitude 
accuracy and star identification. Obtain detailed 
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timing estimates to determine any potential prob- 
lems when the software is transferred to the target 
microprocessor (the Intel 8086) . 

5. Transfer AADS to the Intel 8086 and determine 
whether the software meets all requirements, in- 
cluding those for execution time. Some interfaces 
with the operating system will be changed to imple- 
ment AADS on the Intel 8086; otherwise, the program 
will be modified only if it cannot meet timing or 
memory requirements. 

6. AADS will be tested in actual flight during an ex- 
periment onboard a spacecraft. The Onboard Support 
Simulator (OSS) and the Sensor Data Simulator (SDS) 
in the AADS simulator will be replaced by the on- 
board computer (OBC) and the Remote Interface Unit 
(RIU) , respectively. The sensor data collection 
(SENSIN) process in AADS will be changed to inter- 
face with the RIU. 

7. AADS will be used on a satellite for attitude de- 
termination and data annotation. 

At present, items 1, 2, and 3 have been completed, and work 
is continuing on item 4. Item 5 will be completed on a time 
available basis when Intel hardware and system software are 
available. 

1 . 3 SYSTEM DESCRIPTION 
1.3.1 AADS SIMULATOR 

The AADS simulator (References 3 and 4) provides commands, 
processing options, and sensor data during system testing 
and provides commands and processing options during a mis- 
sion. Thus, AADS communicates with the operator through the 
AADS simulator. Figures 1-1 and 1-2 depict the AADS inter- 
faces with the AADS simulator and the related data flow. 
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Figure 1-1. AADS System Testing Configuration 
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The AAOS simulator consists of several, separate processes. 
These processes are briefly described below. 

1 . 3 . 1 . 1 Ground Support Simulator (GSS) 

GSS executes on the VAX to perform three major functions: 
uplink data preparation, uplink data and commands to AADS, 
and telemetry reception and output reporting. GSS also 
sends data and commands to the OSS during the ground testing 
of AADS . 

GSS displays the AADS commands and processing options, and 
the OSS processing options, for operator input. GSS then 
formats the commands and data as transmission messages to be 
uplinked. GSS also rv^ceives the output from AADS and pre- 
pares formatted output for the operator. GSS displays the 
activity log during AADS operation and prepares and prints 
plots and tables of the attitude information downlinked by 
AADS . 

1 . 3 . 1 . 2 Sensor Data Simulator (SDS) 

SDS reads gyro and star tracker data from a sequential file 
created by the Landsat simulator and sends it to AADS. Be- 
cause the data are available from the sensors onboard the 
spacecraft, SDS is not needed during a mission. Gyro data 
are available at 64 milliseconds, and star tracker data, at 
50 milliseconds for alternate star trackers; these periods 
can be varied by option (multiples of the minimum period) . 

In addition, SDS reads header information from the simula- 
tion tape. The header (containing such information as ini- 
tial attitude, biases, and alignment matrices) and the raw 
sensor data are formatted and printed by the AADS simulator 
for the analyst. Header information is also made available 
to GSS for preparing uplink data to AADS. 
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1.3. 1.3 Onboard Support Simulator (OSS) 


OSS simulates the OBC during testing and simulation and 
forms the link between AADS and GSS. OSS accepts commands 
and data from GSS and then retransmits the AADS information 
to AADS. AADS sends annotated data and other reports and 
error messages to OSS for retransmission to the ground. 
Periodically, AADS requests and receives spacecraft ephem- 
eris from OSS; OSS itself receives the orbit propagation 
conditions from GSS. 

1.3.2 AADS 

AADS comprises several coordinated standalone programs 
(processes) that process sensor data and determine space- 
craft attitude in real time. Figures 1-3 and 1-4 are the 
AADS baseline diagrams. These diagrams are for AADS as a 
whole and for various processes within the system. Fig- 
ures 1-3 and 1-4 show the AADS external and internal inter- 
faces, respectively (see Figure 3-1 in Section 3 for 
definition of flowchart symbols used) . 

1.3. 2.1 Executive (EXEC) 

The executive acts as a miniature operating system and con- 
trols the various processes (standalone programs) in AADS. 
It uses a table of process priorities and periods to sched- 
ule the processes. All priorities and scheduling periods 
are variable and are set by command from the ground. The 
executive sets up a timer request for the "next call" when- 
ever it schedules a new process. It starts a new process 
w-hen the previous process completes or when a timer request 
matures. The executive computes the occultation of star 
cameras, checks for spacecraft maneuver indicators set by 
dther processes, and uses special scheduling during these 
conditions. Finally, the executive keeps a log of activi- 
ties performed and errors encountered during scheduling. 
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1. 3. 2. 2 Input 

Two separate processes (SENSIN and INPUT) perforin the input 
function. SENSIN executes at a high priority to access gyro 
data (every 64 milliseconds) and star tracker data (every 
100 milliseconds for both star trackers) . SENSIN stores the 
data in a global COMMON area for use by the attitude compu- 
tation processes. The INPUT process periodically receives 
(nominally every 20 minutes) the ephemeris information sent 
by the OBC(OSS). INPUT also accepts the commands and data 
sent from the ground by means of the OBC(OSS). The commands 
are then decoded and given to EXEC for immediate action. 

EXEC resumes the INPUT process later# when AADS is idle# to 
validate and store the ephemeris and uplinked processing 
options. 

1 . 3 . 2 . 3 State Propagation 

State propagation is performed by two separate processes; 
GYPROC# which validates and converts gyro data# and PROPAG# 
which propagates the state and the state covariance matrix. 
Nominally called every 512 milliseconds# these processes use 
gyro data accumulated during that period. The scheduling 
periods for both GYPROC and PROPAG are variable and can be 
changed by ground command. GYPROC decodes the gyro data to 
determine whether a maneuver is in progress. It validates 
gyro counts and converts the counts into angles. PROPAG 
uses these angles to compute the spacecraft angular veloc- 
ity# which is then used to propagate the state and the state 
covariance matrix. The propagated state is used for data 
annotation. 

1.3. 2.4 State Update 

The state update function is performed by three separate 
processes: STRACK , STARID # and UPDATE. STRACK collects and 

validates star tracker data and groups star observations. 

The update period depends on the availability of star data# 
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tracker group formation options, and scheduling periods for 
the STRACK process. STARID matches those star observations 
with stars from the star catalog; UPDATE updates the state 
and the state covariance matrix using the observed and pre- 
dicted (catalog) stars. The state update is nominally per- 
formed as soon as at least one star is identified (all times 
are variable and are set by command from the ground) . 

UPDATE uses observations (unit star vectors) in a Kalman 
filter to correct the current state for errors that may have 
accumulated during state propagation using gyro data. 

The executive schedules the STRACK process whenever gyro 
saturation is detected during gyro data validation. This 
condition indicates a possible loss of attitude; therefore, 
immediate star identification followed by state update is 
necessary to determine the correct attitude. 

The executive suspends star data processing during space- 
craft maneuvers and when both star cameras are occulted. 
During these periods, state propagation can be performed at 
a higher frequency to limit attitude error. 

1.3. 2. 5 Output 

The OUTPUT process is scheduled by the executive for pe- 
riodic output of annotated data (after state propagation) , 
performance reports (after state update) , and ephemeris re- 
quests (nominally every 20 minutes) . All periods are vari- 
able and are set by ground command. OUTPUT is also invoked 
when a critical error is detected and sends the activity 
log, sensor data report, and an error message to the ground. 

Annotated data include time-tagged spacecraft attitude 
data. Performance reports contain information about star 
data processing and update, and the activity log contains 
scheduling information, important events, and error indica- 
tors. The raw sensor data report contains gyro and star 
data collected during a short time period just preceding the 
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ecror event. The ephemeris request is for a 20-minute span/ 
and sent in a lookahead manner when the ephemeris data that 
remain in the ephemeris arrays are sufficient for the next 
update cycle. 

1.4 DESIGN STATUS 

1.4.1 HOW THE REQUIREMENTS ARE MET 

Figures 1-3 and 1-4 and Table 1-1 show that all the major 
functional requirements are met. The baseline diagrams in 
Section 3 and the component descriptions (prologs and PDL) 
in Volume II show that all detailed requirements are satis- 
fied. Attitude accuracy requirements will be met by the use 
of a Kalman filter. 

1.4.2 CHANGES IN THE PREVIOUS DESIGN 

The following changes have been made to the previous design: 

• Sensor data access using direct-memory access (DMA) 
in Intel 8086 version of AADS. 

• Pairwise star matching technique required when cur- 
rent attitude uncertainty exceeds specified toler- 
ance. 

e No triplet star matching technique required. 

• No occultation table necessary; occultation com- 
puted onboard using Sun/Moon/Earth ephemerides. 

• SENSIN process does not check for gyro saturation; 
check is performed in the GYPROC process. Gyro 
saturation indicates possible loss of attitude; 
therefore/ executive immediately schedules STRACK, 
STARID/ and UPDATE processes to update state. 

• Gyro rates are computed using valid end points in 
gyro data and not by accumulating individual valid 
increments. 


Table 1-1. Scheduling Activities of AADS 
Period^ 


Function 

Priority 

(nominal) 

Comments 

EXEC 

High 

NA 

Schedules other processes 

SENSIN 

High 

100 msec 
64 msec 

Collects data from both 
star trackers; collects 
gyro data 

INPUT 

High 

High 

20 min 

Receives commands; receives 
and stores ephemeris data 


Low 

After a 

major 

cycle^ 

Updates tables and vali- 
dates tables and ephemeris 
data 

OUTPUT 

Med 

512 msec 

Outputs annotated data 
every nth propagation 


High 


Outputs update report 
every n updates 


High 

Critical 

error 

Outputs activity report, 
sensor data report every 
m propagations 


Med 

High 

20 min 

Outputs ephemeris request; 
outputs error messages 

GYPROC 

Med 

512 msec 

Performs gyro data process- 
ing 

PROPAG 

Med 

512 msec 

(or every nth gyro data 
processing) 

STRACK 

Low 

2.0 sec- 
onds 

Nominally, starts imme- 
diately after a state update 

STARID 

Low 


Scheduled when sufficient 
star groups formed by STRACK 

UPDATE 

Low 


Scheduled when sufficient 


stars identified by STARID; 
error message sent when no 
state update for 7 minutes 


'''All periods can be changed by ground command. 

2 

A major cycle includes all activities up to and including a 
state update. 


1-17 



• The attitude computation function was changed to 
implement the new and/or changed requirements de- 
scribed in Section 1.2.2. AADS will now automati- 
cally adjust the star identification procedure 
depending on the current attitude uncertainty. For 
example, larger window sizes and pairwise matching 
algorithms, will be automatically used when the 
current attitude uncertainty exceeds a user- 
specified tolerance. In addition, the regular form 
of the Kalman filter will be used for attitude de- 
termination., 

1.4.3 AREAS OF CONCERN 

The following areas of concern have been identified. They 
do not hamper the implementation of a prototype AADS on the 
VAX computer, but should be considered for the final AADS 
version on the Intel 8086 computer, and the version of AADS 
Useid during a satellite mission. 

• Function of the RIU is not understood very well. 

The AADS simulator does not simulate RIU functions 
accurately. 

• Data collection for downlink telemetry is not 
understood very well. 

• Communications protocol between AADS and the OBC 
(OSS) is not defined very well. 

• Time required to transmit a buffer from the OBC to 
AADS or vice versa is not known. 

• The real-time system clock proposed for AADS may 
slow down testing if high-priority time is not 
available on the VAX-11/780. Long simulations will 
need extensive programmer-present time, a condition 
that could affect other VAX users adversely. 
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• Hardware test procedures for RAM, ROM, and CPU 
should be established to verify system integrity. 

• Electrically erasable programmable memory (EPROM) 
should be considered as an alternative to RAM to 
ensure system integrity and reliability. 

1.5 DESIGN CRITIQUE 

1.5.1 DESIGN RATIONALE AND ALTERNATE DESIGNS 

The paragraphs below explain the rationale for the AADS de- 
sign and describe alternate designs. 

Design Constraints . All constraints must be satisfied as 

follows: 

• The target microprocessor has no peripherals; 

240K byte available memory; 64K-byte process si 2 e 

• Gyro propagation performed in 512 milliseconds; 
attitude update in at least 7 minutes 

f» 30-arc-second (3a) accuracy for each of the three 
axes 

• Must be autonomous for long periods (that is, the 
entire star catalog must be stored in memory) 

Design Goals (Optimize) . Major design goals are as follows 

• Clear, simple, flexible design; major scheduling 
logic visible from the executive and not hidden 
inside the individual processes 

• Functional integrity 

• General purpose (nonspecialized) 

• Portable between different computers 

• Minimum overhead 
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The design presented in this document has been examined to 
see whether it meets the design constraints and optimizes 
the design goals. Results of the examination are as follows 

1. Completeness . The design meets all functional re- 
quirements. The specified accur’acy is expected to be 
achieved by using a Kalman filter. Several components in- 
fluence the accuracy. These include gyro errors, bias 
drift, star identification, star measurement, and dynamic 
errors in quaternion computation. The Kalman filter reduces 
only the observation residuals. 

Time . A rough estimate made during the previous 
design period (References 11, 12, and 13) shows that a 
single execution of all ADDS attitude determination proc- 
esses will require approximately 260 milliseconds for the 
worst-case scenario, leaving nearly 50 percent of the 
512 milliseconds processing time period available for input/ 
output and other activities. However, it is possible that 
AADS cannot meet timing requirements because of unforeseen 
circumstances. Then, either AADS code must be optimized 
with respect to time, or the gyro propagation period must be 
increased. Time optimization, if required, will be per- 
formed after AADS is implemented. Analysis of AADS test 
runs should point out those areas of code whose execution 
efficiency will significantly lower the execution times. As 
a rule of thumb, 20 percent of the code uses 80 percent of 
the execution time. Time optimization can be achieved by 
redesigning this 20 percent of the code if the system does 
not perform within the available time. A simple design will 
permit redesign without a large effort. 

Time optimization may not be necessary if the attitude ac- 
curacy requirements can be met using a gyro propagation 
period of 1024 milliseconds. GSFC and CSC personnel are 
analyzing the attitude propagation algorithm to determine 
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the maximum gyro propagation period that satisfies accuracy 
requirements. 

The Intel 8086 has been shown to be approximately twice as 
powerful as the NSSC-1 microcomputer (Reference 13) that was 
used for attitude determination and control of the SMM 
spacecraft. In the near future, there will be newer ver- 
sions of the Intel and other microcomputers that will be 
more powerful than the Intel 8086. The portability of AADS 
(use of FORTRAN) will allow it to be implemented on these 
later version microcomputers without major changes to the 
design. Thus, time requirements can be also met by using 
newer microcomputers if necessary. 

3. Memory . A study (Reference 11) performed during 
the previous design period (Task 92300) gave an estimate of 
approximately 175 kilobytes of memory for AADS component 
processes. The star catalog was estimated at 142 kilobytes 
of memory for all SKYMAP stars with star magnitudes between 
2.0 and 6.5, a major portion of the available memory; there- 
fore, memory optimization efforts were directed toward com- 
pressing the star catalog. In the previous design of the 
star catalog, some redundant and unnecessary information was 
stored. Task personnel have redefined the AADS star catalog 
structure to reduce the space requirement to 55 kilobytes. 
However, additional logic and computer time are needed to 
decode the contents of the star catalog. Task personnel 
have verified through test runs that this additional time 
does not adversely affect the performance of AADS. 

The AADS processes require approximately 107 kilobytes of 
memory space and 67 kilobytes for the global COMMON areas 
including the star catalog (see Section 4.2.3 for further 
information). Thus, the design satisfies the memory con- 
straints when AADS is implemented on the VAX computer. How- 
ever, it is possible that the size of the AADS executable 
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images will increase when the Intel 8086 FORTRAN compiler is 
used to compile the AADS source code. Using a conservative 
expansion factor of 2,0 between the object code produced by 
the VAX FORTRAN compiler and the Intel 8086 FORTRAN com- 
piler, the memory requirement would be approximately 
320 kilobytes. This means that AADS can be tested on the 
Intel microcomputer development system (MDS) , but cannot be 
implemented on the target microcomputer (with 240 kilobytes 
of memory) . However, a precise determination of the object 
code expansion factor is needed before attempting any memory 
optimization. 

4. Overhead . The Intel operating system (under devel- 
opment) will support shared global COMMON areas but will not 
support a shared mathematical function library. This li- 
brary is expected to require approximately 2 kilobytes of 
memory, and each process must be built with a separate copy 
of the library. Some of this overhead can be reduced by a 
proper combination of some processes or if reentrant code is 
supported by the FORTRAN compiler. Again, this combination 
should be made so that the design retains its flexibility 
and the main scheduling logic remains in the executive (not 
hidden in the lower level components) , All interprocess 
communication will be via global COMMON areas; therefore, 
this factor should not affect the design. 

5. Design Goals . The design team feels that the cur- 
rent design satisfies all design goals. It is a simple de- 
sign that achieves functional integrity by assigning a 
separate process for each major function. Design flexibil- 
ity was demonstrated by the fact that a major change in the 
star identification requirements--use of a more powerful 
pairwise matching technique--was implemented very easily 
without appreciable impact on the design schedule. Task 
members have also determined that simple changes to the 
logic of the executive main driver and the process schedule 
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table will allow the addition of a coarse attitude determi- 
nation system for enhanced versions of AADS. The system is 
portable through the use of FORTRAN as mentioned earlier. 
Thus, it can be implemented on newer microcomputers that 
support a multiprocessing operating system and standard 
FORTRAN compiler and can satisfy other basic memory and time 
requirements. Therefore, the present design was selected. 
However, other designs are shown and compared with the cur- 
rent design. 

1.5.2 ALTERNATE DESIGNS 

The alternate designs listed below were considered. 

1. Design A . Current design. 

2. Design B . Single process (load module) . All asyn- 
chronous actions taken using the vectored interrupt 
facility. 

3. Design C . Groups processes as follows; 

• EXEC 

• SENS IN, INPUT, OUTPUT 

• GYPROC, PROPAG, STRACK, STARID, UPDATE 

4. Design D , No executive process. The operating 
system performs the executive functions as was done 
for the SMM OBC program (Reference 13). 

5. Design E . Groups processes as follows: 

• EXEC 

• SENS IN 

• INPUT 

• OUTPUT 

• GYPROC, PROPAG 

• STRACK, STARID, UPDATE 

Design B . The executive will be the main driver. All other 
processes will become subsystems and will be called by the 
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executive (not scheduled) . This design may not be techni- 
cally feasible, and it would be very difficult to implement 
regardless of its feasibility. The subsystems will be 
called in succession only when the previously active subsys- 
tem is completed. All asynchronous processes will be called 
by the operating system via vectored interrupts. The SENSIN 
process will be called after a timer interrupt to collect 
data at a high frequency. The high-frequency state propaga- 
tion may have to wait for state update completion since the 
executive will not be able to suspend and resume processes. 
This design shows that, in general, functions that are 
performed at different frequencies should be designed as 
separate processes. This philosophy was used for Design A. 

Design C . Functional integrity is destroyed because several 
diverse functions are grouped together without logical 
reason. Consequently, the clarity of design is destroyed; 
all the major scheduling logic is taken out of the executive 
and placed inside each process. 

Design D . The operating system will assume the executive 
function of process scheduling; execution will be table 
driven. Each process will have an entry in the table. The 
entry will consist of the process location, priority, and 
period. Processes will be given control at the location 
given in the tables. Because this design was successfully 
used for the SMM mission, it will be compared in greater 
detail with the current design (Design A) . See Reference 13 
for further details on Design D. 

Design D Design A 

1. Processes are accessed by Processes are accessed by 
location in the table. name. Scheduling is speci- 

Therefore, the system is fic to mission but there- 
more general. fore easier to understand. 
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Design D 


Easy to change processes 
when either sensors or 
the computational methods 
are changed. Only the 
new table has to be de- 
signed. 

Nonnominal processing 
will be handled to a 
greater extent by each 
process. This logic will 
be hidden inside the 
process. 


The operating system is 
microprocessor-specif ic. 
It is usually written in 
the assembly language 
for that particular 
microprocessor and is 
very economical with re- 
spect to execution time 
and memory. 

Not a portable system. 
Difficult to maintain be- 
cause of assembly lan- 
guage coding. 


Design A 

The executive must be modi- 
fied to accommodate new sen- 
sors and so on. 


Nonnominal processing is 
handled at the top level by 
the executive resulting in 
simpler control at the top 
level. For example, the 
special processing requested 
during occultation is 
clearly seen at the execu- 
tive level. 

Cannot be as efficient. 


Can be used on a different 
microprocessor if a com- 
piler is available. It will 
be easier to maintain be- 
cause of the use of a 
standard language. 


Design A has been selected because of the importance of fac- 
tor 5. In addition, Design D cannot be used because the 
specific microprocessor to be used for a flight-qualified 
AADS had not been defined at the time of design and because 
a fair amount of work had been already completed on Design A. 

Design E . This design is similar to (current) Design A ex- 
cept that some of the processes have been combined. This 
will save approximately 6 kilobytes of memory since the 
mathematical function library will not be duplicated in the 
combined processes. However, additional logic will be 
needed inside these combined processes because gyro data 
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processing and state propagation functions are performed at 
different frequencies and if star identification is per- 
formed on each star group instead of on all groups. Because 
the 6-kilobyte memory savings achieved in Design E is not 
critically important, Design A was selected. However, the 
design can be modified if the experience gained during im- 
plementation of the prototype warrants it. It is also ex- 
pected that redesign because of requirement changes will be 
easier because of the simplicity and flexibility of the cur- 
rent design (Design A) . 

Given that the scheduling requirements for the attitude com- 
putation functions have stabilized during the development 
period. Design E could have been selected instead of De- 
sign A. Again, the selection of Design E would put some of 
the scheduling logic inside the component processes instead 
ofi the executive. More important is a further change in 
scheduling requirement may require a large redesign effort 
depending on the nature of the change. 

1.5.3 SUGGESTIONS FOR IMPROVEMENT 

• Run the program on the designated computer under 
various conditions to obtain timing and accuracy information 

Use different frequencies for gyro propaga- 
tion, output, and star processing to find op- 
timal conditions. 

Record all identified stars during long pe- 
riods for studying star catalog requirements 
and performance of the existing star identifi- 
cation methods. 

Run a Boole & Babbage Problem Program Evalua- 
tor (PPE) (Reference 14) , if available, to 
obtain accurate timing estimates. 
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• Change the program only if current requirements are 
not met or if requirements have changed. 

• It is possible that the accuracy requirement can be 
achieved at a gyro propagation period of 1024 milliseconds. 
Thus, the 1024~millisecond period may be used if attitude 
computation cannot be performed in the 512 milliseconds 
available or if more powerful star identification and atti- 
tude update methods are desired. 

• Identify code for optimization. For example, star 
identification and state update will require large amounts 
of time, but it may not be possible to shorten the time re- 
quired. The SENSIN process mciy be more critical since it 
runs at a high frequency. The sensor data collection func- 
tion is quite easy and, therefore, may be coded in the Intel 
assembly language to minimize execution time. 

• Consider reducing the size of the star catalog by 
omitting stars dimmer than a stellar magnitude of 6.2. 

There are approximately 1000 stars between the magnitude 
range of 6.2 to 6.5. This will save nearly 12 percent of 
the space required for the present catalog (8500 stars be- 
tween the magnitudes of 3 to 6.5). This space may be used 
for other processes if required. 

• Consider more powerful star identification methods 
such as triplet matching. 

• Consider the addition of a coarse attitude determi- 
nation function (Sun-magnetometer (Sun/Mag) sensors or Sun/ 
infrared (Sun/IR) sensors) . These functions could compute 
attitude to within a degree or less. This will make AADS 
completely autonomous since initial attitude estimates for 
star identification and attitude update can be provided by 
the coarse attitude function if required. The addition of 
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this function may also satisfy the current time and memory 
constraints in the following ways: 

- Coarse attitude determination will be per- 
formed only when the attitude is not known to 
the accuracy required by the star identifica- 
tion process. Star identification will not be 
performed during this time. 

Direct or simple pairwise matching techniques 
may be used since attitude is known accur- 
ately; this will mean a simpler and smaller 
star identification process. 

1 . 6 AADS OPERATION INFORMATION 

1.6.1 OPERATION ON THE VAX COMPUTER 

Executable images of all processes in AADS and the AADS sim- 
ulator reside on the VAX disk files. A DCL procedure is 
used to initiate a simulation. GSS, SDS, and OSS (see Sec- 
tion 1.3.1) are invoked to start the simulation. SDS reads 
the header information from the simulation tape and makes it 
available to GSS for setting up commands and data for up- 
link. SDS also starts sensor data transmission to AADS to 
simulate the condition during a mission when the attitude 
sensors are active, even though AADS itself is not active. 
The operator selects AADS commands and processing options 
and OSS orbit propagation information from the displays pro- 
vided by GSS and then sends this information to AADS via 
OSS. Section 1.6.4 describes in detail a startup scenario 
and AADS scheduling. 

GSS accepts AADS output transmitted via OSS and prints it 
for operator evaluation. Attitude information and other 
information on biases, validation statistics, and star iden- 
tification is plotted or printed in a tabular format as re- 
quired for evaluating the simulation results. The operator 


can test and/or control the system by sending new commands 
and new processing options. The available commands are as 
follows: 

Command Function 

START Synchronizes AADS clock and starts AADS opera- 

tion 

STOP Performs an orderly shutdown of AADS after 

completing pending functions; AADS then goes 
into a "wait" state until a new START command 
is sent from ground 

HALT Halts star data processing and state update; 

state is propagated using gyro data 

RESUME Resumes star data processing and update func- 

tions 

SET CLOCK Synchronizes AADS clock to correct any time 
drift 

Clock synchronization is not needed for the VAX version of 
AADS because the VAX clock maintains a single time for all 
processes in AADS and the AADS simulator. The SET CLOCK 
command is not implemented in the current version of AADS. 

1.6.2 OPERATION ON THE INTEL-VAX COMPUTERS 

To reiterate, the executable images of all processes reside 
on the VAX disk files; however, the AADS process images are 
stored in the Intel absolute object image format. All AADS 
simulator processes are invoked and prepared for the start 
of simulation as described in Section 1.6.1. At this point, 
a utility program on the VAX transmits the AADS process 
images to the Intel, where a loader loads the programs in 
memory, and gives control to the AADS executive. The cur- 
rent VAX time is transmitted to the Intel at the very end of 
the loading operation and is stored in a specified area of 
AADS. The startup and consequent operation of AADS is iden- 
tical to that process described in Sections 1.6.1 and 1.6.4, 
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except for the following internal differences that do not 
affect the user: 

1. A clock in the Intel computer maintains AADS time. 
However, this time is synchronized with the AADS time with a 
timer pulse taken from the VAX clock. 

2. Communication between the AADS simulator and AADS 
is through the Intel operating system. In particular, the 
Intel operating system reads the sensor data transmitted by 
SDS and makes it available to AADS, in a specified area in- 
side AADS. This procedure simulates, as closely as pos- 
sible, the function performed by a hardware device known as 
the RIU. The RIU accesses the data from sensors onboard the 
spacecraft and writes the data in a specified area in AADS 
memory. 

1.6.3 CHANGES TO THE SYSTEM DURING FLIGHT QUALIFICATION 

For actual flight usage the following changes will take 
place: 

• AADS will execute on the Intel 8086 computer. 

• The OSS will be replaced by the OBC. 

e The SDS will be replaced by an RIU or some other 

hardware device that will directly update the data 
buffers using shared memory or direct-memory access 
techniques. The sensor data collection (SENSIN) 
process will be redesigned if necessary. 

• The timing signal from the VAX-11/780 will probably 
be replaced by a central time base onboard the 
spacecraft. Code for accessing time may be 
changed. In addition, the SET CLOCK command may 
have to be implemented. 
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1.6.4 AADS STARTUP SCENARIO AND FLOW DIAGRAM 


This section contains a startup scenario for AADS data 
processing when AADS is implemented on the Intel computer. 
Figure 1-5 is a flow diagram of the process. 

The following events describe the startup scenario: 

• After uplink, the operating system is running. The 
executive has been invoked. Various processes are 
initialized in a dormant (suspended) state except 
for the input data processing (INPUT) process, 
which is active and waiting for input after issuing 
a read request. No sensor readings are being taken. 

• Uplink data to update several COMMON areas may be 
received. These COMMON areas contain AADS control 
parameters. 

• A START command is received from the ground (any 
other command is invalid at this stage) . The INPUT 
process accepts the command, sets a flag for the 
executive, issues another read request for future 
input, and suspends itself. As part of the startup 
procedure, the ground has sent time information to 
the operating system, and the system clock has been 
synchronized. This may be done when the system is 
initially loaded. 

• The executive schedules the output data processing 
(OUTPUT) process to generate an ephemeris request 
and schedules the gyro data processing (GYPROC) and 
SENSIN processes. The OUTPUT process is scheduled 
at the proper frequency for data annotation output. 

• The executive computes star camera occultation from 
ephemeris information. The star data processing 
functions are not invoked if (1) ephemeris data are 
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STARJO OR UPDATE IS RUNNING 
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NOTE: THE INPUT TASK HAS RECEIVED lOPTIONALI TABLE UPDATE FOLLOWED BY A START COMMAND. 

CASES SHOWN INCLUDE NORMAL PROCESSING. PROCESSING DURING MANEUVER, AND PROCESSING 
WHEN the UPDATE TASK IS INTERRUPTED AND DELAYED BY GYRO PROCESSING. 


Figure 1-5. Normal Processing: AADS Initialized 
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not available, (2) stai: cameras are occulted, or 
(3) the spacecraft maneuver flag is on. 

• Under normal circumstances (ephemeris data avail- 
able, no occultation, and no maneuver) , the ex- 
ecutive will schedule the following processes: 

- High-frequency, high-priority SENSIN process 
to collect sensor data and perform some vali- 
dation 

High-frequency gyro processing and propagation 
processes to propagate attitude 

- OUTPUT process for attitude results to anno- 
tate science data 

High-frequency star data processing process to 
collect star data, to perform data validation, 
and to form tracker point groups 

NOTE : This process is rescheduled at a high 

frequency N seconds after an attitude 
update and continues periodically until 
the next update. 

- Star identification and attitude update proc- 
esses, respectively to output when sufficient 
star groups are formed and sufficient stars 
are identified 

OUTPUT process to output attitude results 
after update 

OUTPUT process to generate ephemeris request 
every 20 minutes 

1.6.5 UPLINK OF CONTROL PARAMETERS 

AADS commands and processing options may be specified inter- 
actively through GSS. The commands are described in 
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Section 1.6.1. AADS processing options are divided into 
four broad categories: 

1. Scheduling frequencies and priorities 

2. Propagation and update parameters 

3. Star processing and identification parameters 

4. Occultation prediction parameters 

A series of menus and parameter displays allows the user to 
enter the desired input. Figure 1-6 shows a sample of AADS 
processing options. See Reference 4 for futher 
information. GSS formats the processing options into 
transmission records, which are then uplinked to AADS. An 
uplink consists of a command and/or one or more of the four 
categories of processing options just defined. The new 
values of the processing options are stored in AADS COMMON 
areas and used thereafter. 

1.6.6 INPUT PROCESSING 

• When the Intel is turned on, it passes control to 
the AADS executive. The executive invokes the 
INPUT process, which in turn issues a read request, 
and then suspends itself. The INPUT process always 
waits for a command, data from the ground, or 
ephemeris data from the OBC/OSS at a high priority. 

- It sets proper flags for the executive when 
commands are received from the ground. 

It stores uplink data for table (COMMON) up- 
dates in a buffer area. 

It updates the ephemeris table from the infor- 
mation given by the OBC. 

• After processing input, the INPUT process issues 
another read request and then suspends itself. 
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STATl/ UPLINK TASK SCHEDULES CYES/NO) NO 

NOMINAL TASK PERIODS 

SNDELTl/ GYRO DATA COLLECTION (SECONDS) 0,064 

SNDELT2, STAR CAMERA DATA COLLECTION (SECONDS) 0.100 

GYDELTl, GYRO DATA PROCESSING (SECONDS) 0.512 

IGYRPl, MULTIPLE OF GYDELTl FOR SCHEDULING PROPAGATION (NO UNIT) 1 

NPROUTl, NUMBER OF TIMES PROPAGATION SCHEDULED BEFORE DATA • 

ANNOTATION REPORT (NO UNIT) 1 

STDELT, STAR DATA PROCESSING (SECONDS) 2.0 

UPLIM, STAR IDENTIFICATION AND UPDATE 420.0 

UPDELT, DIFFERENCE BETWEEN THE LAST SCHEDULED UPDATE AND NEXT 

STAR DATA PROCESSING (SECONDS) 30.0 

GYRO PERIODS DURING A MANEUVER 

GYDELT2, GYRO DATA PROCESSING (SECONDS) 0.256 

IGYRP2, MULTIPLE OF GYDELT2 FOR SCHEDULING PROPAGATION (NO UNIT) 1 

NPROUT2, NUMBER- OF TIMES PROPAGATION SCHEDULED BEFORE DATA 

ANNOTATION REPORT 1 

Figure 1-6. Sample of AADS Options 


The executive will reactivate the INPUT process at 
the end of a major cycle to update COMMON areas or 
to validate ephemeris data and information received 
earlier. A major cycle includes all AADS activi- 
ties up to and including a state update. 

COMMON areas are updated at the end of an attitude 
update (major cycle) so that the attitude computa- 
tion will not be disrupted during a major cycle. 

If several COMMON areas are to be updated/ the 
ground will send commands to STOP processing, to 
update COMMON areas, and then to START processing. 



SECTION 2 - SPECIFICATIONS SUMMARY 


This specifications summary has been compiled from Refer- 
ences 5 through 15, and those documents should be consulted 
for further details. Specific references also appear in the 
text. 

2.1 MAIN REQUIREMENTS 

The main AADS requirements are as follows: 

• AADS will compute the spacecraft attitude to anno- 
tate science data onboard the spacecraft. 

• The AADS design will meet the requirements of 
NASA's MMS series. It will support spacecraft with 
attitudes that either vary smoothly in time 
(Landsat-D type) or are nearly inertially fixed 
(SMM type) . 

e AADS will maintain an attitude accuracy of 30 arc 
seconds (3a) for each axis. 

• AADS will perform in a real-time mode and in an 
autonomous manner for a long period of time and 
will require only infrequent ground support. 

• AADS will accept commands and data from the ground 
and will transmit attitude results^ update results, 
activity logs, error messages, and raw sensor data 
to the ground. 

• AADS will be implemented as a portable modular unit 
on a microprocessor onboard the spacecraft. The 
microprocessor will have 256 kilobytes of memory 
and no peripheral devices. A prototype system will 
be implemented on a VAX-11/780 computer to test 
feasibility. 
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• AADS will use gyro and star tracker data. Gyro 
data are used to propagate attitude, and data from 
identified stars are used to update the attitude 
using a linear optimal filter (Kalman filter) that 
is stable against roundoff errors. 

• AADS will provide for contingencies and error han- 
dling. 

2.2 DESIGN CONSTRAINTS 

AADS will have the design goals of functional integrity, 
functional strength, flexibility of design, and maintain- 
ability, while meeting the following design constraints: 

• 240 kilobytes of memory space is available for 
AADS. No peripheral devices will be available, compelling 
all code and data to reside in memory. 

• Multiprocessing is supported. Maximum process size 
is restricted to 64 kilobytes of memory for instructions and 
64 kilobytes of memory for data. Overlay structures are not 
permitted . 

• AADS will execute in real time. It will perform 
gyro processing and propagation within a nominal period of 
512 milliseconds and will update the attitude using star 
tracker data nominally at least once every 7 minutes. These 
periods are variable and can be changed during processing by 
ground commands. 

• AADS will use a propagation and update scheme to 
compute the attitude with an accuracy of 30 arc seconds (3a) 
for each axis. Variables that are required to be used in 
double-precision to achieve accuracy goals will be identified 

• AADS will be implemented initially on a VAX-11/780 
computer for test purposes. Later, it will be transferred 
to a microprocessor. (The target microprocessor is the 
Intel 8086. ) 
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Th^ following design changes will be necessary before trans- 
fer to the target microprocessor can be accomplished: 

(1) modify the input and output interface components if re- 
quired to provide proper communication , (2) modify the sys- 
tem clock logic to interface with the Intel operating 
system, and (3) establish specific memory maps as required. 

2.2.1 HARDWARE REQUIREMENTS 

AADS hardware requirements are as follows: 

• AADS code developed and tested on the VAX-11/780 
will be downloaded to the Intel 8086/8087. The code will be 
downloaded using the same asynchronous parallel line over 
which the VAX-installed simulators and AADS communicate. A 
micro-based operating system and Intel-VAX communications 
software will be resident on the Intel. System software 
will be available to compile AADS source and create AADS 
executable images on the Intel 8086. 

The target computer should be equivalent to the Intel 8086 
microprocessor with respect to execution time, memory re- 
quirements, and system architecture (see Reference 12 for 
additional details and specific values) as follows: 

• Memory addressing capability of 256 kilobytes 

• Direct addressing capability of 64 kilobytes 

• Cycle times, memory access times, and instruction 
execution times comparable to the Intel 8086 

• Floating-point arithmetic capability with an effi- 
cient floating-point instruction set, including 
single- and double-precision add, subtract, mul- 
tiply, and divide instructions 

• 16-bit arithmetic, addressing protection, interrupt 
for arithmetic exception, mechanisms to provide for 
position-independent code 
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Communication between the VAX-11/780 computer and the 
Intel 8086 will be needed during development and testing. 
Figures 2-1 and 2-2 show a typical system configuration. 

2.2.2 OPERATING SYSTEM REQUIREMENTS (Intel-VAX CONFIGURA- 
TION) 

The Intel operating system requirements are as follows: 

• A number of system software packages must be devel- 
oped for the Intel 8086 and VAX-11/780 to execute AADS and 
the AADS simulator simultaneously. 

• The Intel operating system must be compatible with 
the VAX operating system, so that major design changes will 
not be needed when AADS is transferred to the Intel. 

• The operating system must support multiprocessing, 
and it must have the capability to initiate (schedule) and 
to terminate process images (up to 64 kilobytes of memory) 
after the process images have been loaded into the RAM of 
the Intel 8086 according to their priority levels. There 
will be no requirement to remove processes after execution 
completion. 

• A designated process (executive) must be able to 
set priorities and to start, suspend, resume, and halt other 
processes. Other processes must be able to suspend them- 
selves. 

• The operating system must provide the following 
services associated with the system timing requirements: 

Time of day and day of year 

An interrupt (approximately) every 10 milli- 
seconds to the Intel for clock maintenance; an 
interrupt after N milliseconds where N is set 
by the executive process 
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Figure 2-1. Computer System Configuration and Information 
Transfer Rates 
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Synchronization (reset) of the clock in re- 
sponse to a ground command 

Process wait and periodic process execution 

• The operating system must support global COMMON 
areas, but the mathematical subroutine library will not be 
shared among processes. The operating system and the mathe- 
matical package will require approximately 16 kilobytes of 
memory. 

• The operating system must be able to detect arith- 
metic exceptions and to take appropriate actions (that is, 
transfer control to an error message routine to generate a 
descriptive message and wait for user action) . The operat- 
ing system will provide addressing protection and bus time- 
out indication. 

• Two parallel channels using DR-llC drivers must be 
available for communication between the VAX and the Intel 
computers. 

• After the AADS prototype is moved to the Intel 8086 
computer, the AADS simulator will remain on the VAX and will 
communicate with the AADS via parallel transmission lines. 

• The operating system must have a facility to accept 
incoming messages from another processor asynchronously. 

When a message is sent via a serial or a parallel line from 
another processor (the VAX) , all currently executing proc- 
esses should be suspended, and a high-priority handler 
should be initiated immediately to accept and store the in- 
coming message. Upon reception, a predetermined flag should 
be turned on to notify any applications software that may be 
waiting for the arrival of the message. Finally, all sus- 
pended programs must be resumed to continue the normal ex- 
ecution. 
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» Assuming that executable images of the operating 
systems and a number of applications programs exist on VAX 
files, a facility to downline load these images into the RAM 
of the Intel 8086 will be needed to run various AADS simula- 
tion cases. This facility would require the development of 
software for both the VAX and the Intel computer systems. 
Only the available (currently existing) interface modules 
will be used for this purpose. The wiring will be deter- 
mined later when the interface is established. The speed of 
data transfer should be at least 9600 bits per second. This 
facility is needed if a cross-compiler and linkage editor 
program resident on the VAX are used to create the Intel- 
executable image. If the cross-compiler is not used, a 
FORTRAN compiler and linkage editor are needed for the 
Intel. (It should be noted that the cross-compiler is not 
needed because the Intel Development System has a FORTRAN 
compiler and linkage editor.) 

• AADS will be implemented using a FORTRAN language. 
However, it is possible that a few assembly language rou- 
tines (invoked by a FORTRAN CALL statement) may have to be 
coded to implement certain data structures, and for time and 
memory optimization, if required. In that case, an as- 
sembler, is needed for the Intel 8086 assembly language. 

• CSC will identify additional operating system capa- 
bilities (such as mailbox, send-receive type communication, 
and utility software) . 

• The operating system will provide any memory dump 
or memory load capability if AADS or the star catalog is re- 
quired to be uplinked and/or downlinked. 


2.2.3 FORTRAN COMPILER REQUIREMENTS 

FORTRAN compiler requirements are as follows; 

• Support double-precision arithmetic 

• Interface with the Intel 8087 numeric data processor 

• Provide a single-precision mathematical subroutine 

library to include trigonometric, logarithmic, and 

other required routines 

• Support calls to assembly language routines via a 
FORTRAN GALL Statement 

2.2.4 AADS SIMULATOR REQUIREMENTS 

AADS simulator requirements are summarized below. See the 
AADS simulator requirements document (Reference 2) for a 
detailed explanation of the requirements. 

• The AADS simulator is intended to support the oper- 
ation of AADS in a laboratory environment. To achieve this, 
it must (1) simulate or provide gyro and star tracker data-- 
Sensor Data Simulator (SDS) , (2) perform onboard functions 
such as spacecraft ephemeris computation and time informa- 
tion — Onboard Support Simulator (OSS) , and (3) simulate 
ground support f unctions--Ground Support Simulator (GSS) . 

• The simulator will provide input test data (simu- 
lated gyro and star camera measurements) and reference out- 
put vectors (for example, reduced and calibrated gyro and 
star vectors and catalog star identification numbers) . 

• Various commands are sent to AADS via the simula- 
tor; in addition, data for AADS control parameter modifica- 
tion is uplinked. The simulator generates reports of the 
telemetry from the spacecraft, attitude results, and activ- 
ity logs transmitted by AADS. 
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• The AADS simulator will provide data from a 
Landsat-D simulator generated tape in the AADS format. See 
Reference 3 for a description of this format. 

• Sensor data (gyro counts, star tracker data, and 
intensity and temperature information) are stored by SDS in 
a buffer area for use by AADS. The data are not queued but 
are refreshed at regular intervals. 

• Gyro data are refreshed every 64 milliseconds. 

• Star tracker data are refreshed at 50-millisecond 
intervals for alternate star trackers (or 100-millisecond 
interval for both trackers) . 

• OSS will contain a full orbit generator. It will 
be able to generate spacecraft ephemeris data for a given 
timespan and frequency. The orbit accuracy is expected to 
be within 500 meters over 24 hours. 

• The gyros will operate in the following two modes: 
(1) high rate mode has a resolution of 0.8 arc-second and a 
saturation value of 1.6 degrees; and (2) low rate mode has a 
resolution of 0.05 arc-second and a saturation value of 

400 arc-seconds. The gyro data will be provided in 24 bits 
containing incremental gyro counts, a low/high mode flag 
bit, and a power on/off bit for each of the six channels. 

• Star camera output includes two 12-bit words for 
horizontal (H) and vertical (V) counts. The H and V counts, 
when converted, give the X and Y components of the unit star 
vector in the star tracker frame. The resolution is 7 arc- 
seconds per count. 

• The AADS simulator will contain options for trans- 
mission failure probability (TFP) and message corruption 
probability (MCP) . 
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2.3 AADS EXECUTIVE REQUIREMENTS 


AADS executive requirements are as follows: 

• The executive will determine scheduling needs using 
a table of active processes, priority levels, and scheduling 
frequencies. 

• The operating system will schedule the highest pri- 
ority process currently pending. AADS executive will sched- 
ule the next subsystem (process) when the current subsystem 
(process) is suspended after using up the allotted time 
slice or after completing its activity. A ground command or 
a critical error will force the AADS executive to take ap- 
propriate action immediately. 

• The executive will perform time slicing by schedul- 
ing "next wake up" call or timer request when a process com- 
pletes. The time slice is implemented by the operating 
system using a mark-time utility function. Round-robin 
Scheduling will be used where possible. This allows proc- 
esses with equal priority to execute one after another dur- 
ing successive time slices. Not all the time slices are 
equal, and some of them are large compared with the usual 
round-robin scheduling. 

• Processes will be scheduled by the executive and 
will use global COMMON areas for interprocess communication. 

• The executive must be compact and. efficient since 
it is executed at the end of each time slice, or when a 
process completes. 

• In the case of severe errors, the executive will 

Schedule activity log, and raw sensor data 
report for immediate downlink 

Schedule messages for immediate downlink 
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- Suspend the error-producing process or take 
other appropriate action 

Allow other processes to continue processing 

In the case of other errors, the executive will 

Enter them in the activity log if required 
Resume normal processing 

• The executive will maintain an activity log con- 
taining statistics relating to the performance of AADS. 

• The executive will initialize AADS. 

• The SENSIN process will be scheduled at regular 
intervals to collect gyro and star camera data for process- 
ing. 

• The executive will time the state update process 
and will generate critical error messages if a specified 
time limit is exceeded. 

• The executive will compute occultation of the star 
camera field of view (FOV) by the Earth and Moon and will 
reschedule the star data processing function as required. 
The executive will compute Moon ephemeris data. The bright 
object sensor will shut down the star camera when the Sun 
approaches the camera FOV. 

• The executive will schedule the OUTPUT process to 
request spacecraft ephemeris. This request will be gener- 
ated when approximately one update cycle (7 minutes) of 
spacecraft ephemeris information remains in the ephemeris 
table. 

• The INPUT process will be given the highest pri- 
ority to capture ground commands or to store spacecraft 
ephemeris data transmitted by the OSS. The INPUT process 
will be resumed immediately after an update to validate 


ephemeris data and to validate and store new table param- 
eters (AADS control parameters) . 

• The executive will check for the maneuver flag set 
by the gyro data processing process and take the following 
actions : 

Reschedule state propagation at a higher fre- 
quency during the maneuver 

Initiate star processing immediately after the 
completion of the maneuver is detected 

2 . 4 INPUT DATA PROCESSING REQUIREMENTS 

AADS input data processing (INPUT) requirements are as fol- 
lows ; 

• AADS will collect sensor data and will accept input 
messages that contain (1) data for updating data bases (AADS 
control parameters), (2) commands generated by ground con- 
trol, and (3) spacecraft ephemeris data transmitted by the 
OBC. The INPUT process will perform input validation. It 
will check for gyro saturation and invalid ephemeris data 
times and intervals. It will also validate input commands 
and other data as required. 

• Commands and data are accepted immediately upon 
transmission. However, validation and table updating (up- 
dating AADS control parameters) occur immediately after an 
update is completed. 

• AADS ground-supplied data base parameters (AADS 
control parameters) include 

process scheduling table, which contains in- 
formation controlling the priority and fre- 
quency of AADS process execution 

- Constants, which will be used throughout AADS 

processing. These will require only infrequent 
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changing. They include scale factors and 
biases for reducing raw attitude sensor data, 
tolerances for editing attitude sensor data, 
and physical constants 

Star catalog table, which contains the coordi- 
nates, magnitudes, and identification numbers 
for SKYMAP stars with stellar magnitudes 
brighter than 6.5. This table is stored in a 
COMMON area 

- Kalman filter initialization parameters, which 
include the a priori state vector, the state 
covariance matrix, and the measurement 
noises. This table will be uplinked at the 
start of AADS execution and then later at the 
user's discretion 

Star identification control parameters, which 
include the tolerances for direct and pairwise 
match tests and the number of stars that must 
be identified before performing state update 

These parameters are described in greater de- 
tail in Section 4.4 and in the AADS simulator 
document (Reference 2) 

. • AADS will accept spacecraft ephemeris data provided 
by the spacecraft onboard computer. 

• AADS will retrieve raw gyro and star sensor data 
that will be available in buffers in AADS memory. However, 
a read request must be issued to read data for the prototype 
version. Star tracker and gyro data will be refreshed in 
the buffers at periodic intervals. A high priority SENSIN 
process will collect star tracker and gyro data for attitude 
computation. The sensor data report will be downlinked in 
the event of a critical error. 



2.4.1 MESSAGE FORMAT FOR UPLINK AND DOWNLINK 

the basic message format for the data transmission between 
the AADS onboard support function and the ground simulators 
will be identical for uplinking and downlinking. The terms 
are defined as follows: 

1. Record--A 20-byte header + data + filler to com- 
prise 256 bytes 

2. Block--A collection of records 

3. Transraission--A collection of blocks in which the 
last record is an end-of-transmission (EOT) record 

The detailed message format is specified in Section 4.6 and 
is described below for convenience. 

• The spacecraft ephemeris request to the OBC/OSS 
will contain start time, period, and number of points 
(20 points, nominally at 1-minute intervals). 

• The ephemeris table will have 40 entries and will 
contain the times along with the vectors for spacecraft po- 
sition and velocity. The table will be stored in a wrap- 
around fashion. There will be no overlapping times in the 
table because of the wraparound design and because the 
ephemeris request is made at least one major cycle in ad- 
vance. 

• AADS control commands, given in the simulator re- 
quirement document, are as follows: 


RESUME 

Resume star processing 

HALT 

Abort star data processing but 
continue to propagate with gyro 
data 

STOP 

Stop current AADS processing in a 
normal manner, that is, finish 
the update process, stop propaga- 
ting, and downlink the last out- 
put; wait for the next command 
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START Start accepting data from sen- 

sors; begin normal propagate/ 
update process when the epoch for 
the initial state is reached in 
real time 

SET CLOCK Set system clock to a new time 

The control variables are described in Section 4.4 and in 
the AADS simulator (AADSIM) requirements (Reference 2) , 
AADSIM will display these variables and block these properly 
for uplink. AADSIM will uplink the commands and/or data in 
the basic format. 

• AADSIM will contain TFP and MCP. See the AADSIM 
requirements (Reference 2) . 

• The acknowledgment procedure (for example, INPUT 
process to the OBC(OSS), OBC to the INPUT process, and 
OUTPUT process to the OBC) has not been determined. 

2.5 ATTITUDE DATA PROCESSING REQUIREMENTS 

AADS attitude data processing requirements are as follows: 

• AADS will provide propagated attitude information 
(for example, spacecraft quaternions and Euler angles) on a 
near-real time basis for experimental data annotation. 

• AADS will use gyro and star sensor data to calcu- 
late, in an optimal fashion, estimates of the spacecraft 
attitude, gyro drift rate biases, and attitude uncertainty. 

• AADS will generate commands requesting spacecraft 
ephemeris from the OBC. Sun and Moon ephemeris will be com- 
puted analytically. 

• AADS will perform any preprocessing necessary to 
edit and validate raw attitude sensor data. 

• AADS will access a resident star catalog that con- 
tains all the SKYMAP catalog stars down to a stellar magni- 
tude of 6.5 (approximately 8700 stars) . The entry for each 
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star will consist of right ascension, declination, and mag- 
nitude. The size of the star catalog will depend on the 
accuracy required for each quantity. Approximately 55 kilo- 
bytes of memory will be needed for the star catalog if 
6 bytes are reserved for each star entry. This will give an 
accuracy of 0.00005 degree for the right ascension and dec- 
lination angles and 0.05 units for star visual magnitude. 

See Section 3.10 for further details. 

• AADS will operate an autonomous mode, receiving 
from the ground only control commands and data for updating 
the onboard data bases. 

Attitude computation is performed by five separate proc- 
esses. The detailed requirements for each process follow. 

2.5.1 STATE DATA PROCESSING REQUIREMENTS 

• Use the specified gyro configuration. 

• Perform checks for limit, consistency, and redun- 
dancy between two gyro channels. 

• Check the gyro rate mode flag for sensing maneu- 
vers. If the high rate mode flag is on, then set a 
maneuver flag for the executive. The executive 
should suspend star data processing functions dur- 
ing the maneuver, and increase gyro data processing 
and propagation frequency. 

• Reset the maneuver flag at the end of the maneuver 
when the gyro rate is low. The executive schedules 
the star data processing functions (if both star 
cameras are not occulted) to obtain an attitude 
update immediately following the maneuver. 

2.5.2 STATE PROPAGATION REQUIREMENTS 

• Use the accumulated gyro data to compute average 
gyro rate. 
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Convert the gyro rate to body coordinates and elim- 
inate drift rate biases. 

Use the gyro rate to propagate the quaternion. 

Propagate the covariance matrix. 

Store the gyro rate, quaternion, and Geocentric 
Inertial (GCI) to body rotation matrix for the star 
data processing processes. 

STAR TRACKER DATA PROCESSING REQUIREMENTS 

Star data will be collected at a high frequency 
until sufficient star groups are formed. The fre- 
quency and duration of data collection is con- 
trolled by table parameters. Star data should be 
collected over relatively short time spans to re- 
duce errors due to attitude propagation over large 
periods of time. 

Perform data editing and grouping. Reject invalid 
data through a limit check on H and V coordinates, 
temperature, and intensity. Reject the beginning 
and ending portion of data from a star. 

Compensate data for stellar image distortion due to 
camera temperature and star intensity effects. 

Correction due to the magnetic field effects is 
expected to be approximately 1 arc second. There- 
fore, magnetic field correction or the South 
Atlantic Anomaly check will not be performed. 

Form track point unit vector in tracker frame, and 
synchronize the unit vector to the nearest gyro- 
propagated quaternion time. 

Rotate the track point unit vector to geocentric 
inertial frame using the nearest gyro-propagated 
attitude. 



• Average the track point unit vectors for each star. 

• Determine the current attitude uncertainty from the 
last state covariance matrix. Select the number of 
star groups that are required to be complete before 
attempting star identification. Select the star 
identification method. 

• Set a flag for the executive when sufficient star 
groups are complete. 

2.5.4 STAR IDENTIFICATION REQUIREMENTS 

• Return with error if spacecraft ephemeris data is 
not available for the data span. 

• Compute solar ephemeris data. 

• Correct observed (average) unit star vector for 
stellar aberration. 

• Correct the star vector for precessional and nuta- 
tional correction that are required because the 
AADS star catalog is created at epoch 2000. 

• Obtain candidate stars from star catalog that are 
in the observation window for each observed star. 

• Perform star identification by direct/pair matching 
techniques. 

• Presently, there is no requirement to use a triplet 
matching technique. 

• Pass observed star vectors and identified star 
vectors to the update process. Set a flag for the 
executive indicating successful star identification. 

• Return with error if identification is not success- 
ful when fewer than the specified number of stars 
are identified in the given time and when a 
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specified percentage of observed stars could not be 
identified . 

2.5.5 STATE UPDATE REQUIREMENTS 

• Compute observed unit star vector in the star 
tracker frame. 

o Compute predicted star unit vector in the star 
tracker frame. 

• Compute observation residuals. 

• Compute partial derivative matrix. 

• Compute the gain matrix. 

• Update the covariance matrix. 

• Update the state vector. 

• Update the drift rate biases. 

• The attitude accuracy is 30 arc seconds (3[) on 
each axis. 

• An attitude update will be performed at least once 
every 7 minutes. Nominally, the updates are per- 
formed as soon as a star is identified. These up- 
date options are controlled from the ground, but 
update frequency depends on the star availability 
and current attitude uncertainty. 

2.6 OUTPUT DATA PROCESSING REQUIREMENTS 

AADS output data processing (OUTPUT) requirements are as 

follows: 

• AADS will output propagated attitudes periodically 
in the form of quaternions and Euler angles (for 
example, roll, pitch, and yaw) for experimental 
data. 


• AADS will output priority messages (critical error 
messages) to request special ground support such as 
error handling. 

• AADS will output samples o£ raw attitude sensor 
data. 

• AADS will output updated values o£ the attitude, 
gyro drift rate biases, state covariances matrix, 
and the Kalman filter gain matrix, as well as the 
SKYMAP catalog numbers of identified stars. (It 
Should be noted that an internal star reference 
number can be sent to the ground to generate the 
actual SKYMAP numbers on the ground.) 

• AADS will generate an activity log. It should be 
noted that the total number of updates attempted 
equals the total number of successful updates. 

• AADS will issue messages requesting spacecraft 
ephemeris data from the onboard computer. The re- 
quest will contain the start time, time increment, 
and number of data points. Nominally, 20 points 
will be requested at 1-minute intervals. 

• The format of a downlinked record is the same as 
the format of an uplinked record. 

• The OBC/OSS will indicate the start time of space- 
craft ephemeris data, which will be validated by 
the INPUT process during ephemeris validation. 

• The OUTPUT process will pass AADS output to the 

. output buffer and will alert the OBC. The OBC(OSS) 
will transmit the output to the ground. 

• The acknowledgment procedure (INPUT process to the 
OBC/OSS, OBC to the INPUT process, and OUTPUT proc- 
ess to the OBC) has not been determined. 
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See Section 4.6 for detailed formats of uplink/downlink mes- 
sages. 

2.7 SPECIAL CONSIDERATIONS 

The following are AADS processing scenarios: 

• INPUT processing scenario. 

• Startup scenario and normal processing (see Fig- 
ure 2-3) . 

• Processing to include star camera occultation; 
suspend star processing during occultation. Resume 
star processing; and update automatically when oc- 
cultation ends. 

• Processing to include a maneuver: suspend star 

data processing and state update; increase gyro 

■ ■ ■ . 'i 

frequency. Resume normal processing when the ma- 
neuver ends. 

• Processing to include a critical error: stars not 

identified in the given time; all gyro data consis- 
tently flagged. 

2.7.1 INPUT PROCESSING 

• The INPUT process always waits for a command, data 
from the ground or epheraeris data from the OBC/OSS 
at a high priority. 

It sets proper flags for the executive when 
commands are received from the ground 

It upduces the ephemeris table from the infor- 
mation given by the OBC 

Data for table update are stored in a buffer 
area 

• After processing input, the INPUT process issues 
another read request and then suspends itself. 
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STARID OR UPDATE IS RUNNING 
TIMER INTERRUPT OCCURS 
NEXT SCHEDULED TASK IS GYPROC 
SUSPEND UPDATE 
COMPLETE GYPROa PROP AG 
OUTPUT ANNOTATED DATA 
RESUME STARID OR UPDATE 
USE ORIGINAL ESTIMATE OP THE 
ATTITUDE BEFORE THE LAST 
PROPAGATION 


NOTE: THE INPUT TASK HAS RECEIVED (OPTIONALI TABLE UPDATE FOLLOWED BY A START COMMAND. 

CASES SHOWN INCLUDE NORMAL PROCESSING, PROCESSING DURING MANEUVER. AND PROCESSING 
WHEN THE UPDATE TASK IS INTERRUP1*ED AND DELAYED BY GYRO PROCESSING. 


Figure 2-3. Normal Processing; AADS Initialized (The 

INPUT process has received (optional) a table 
update followed by a START command, ) 
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• The executive will reactivate the INPUT at the end 
of a major cycle to update COMMON areas or to vali- 
date ephemeris data and information received 
earlier. 

• COMMON areas for AADS control parameters are up- 
dated at the end of a state update (major cycle) so 
that the attitude computation will not be disrupted 
during a major cycle. If several COMMON areas are 
to be updated, the ground will send commands to 
STOP processing, to update COMMON areas, and then 
to START processing. 

2.7.2 AADS STARTUP SCENARIO 

The following events describe the startup scenario; 

• After uplink, the operating system is running. The 
executive has been invoked. Various processes are initial- 
ized in a dormant (suspended) state except for the INPUT, 
which is active and waiting for a command after issuing a 
read request. No sensor readings are being taken. 

• Commands to update several COMMON areas may be re- 
ceived. 

• A START command is received from the ground (any 
other command is invalid at this stage) . The INPUT process 
accepts the command, sets a flag for the executive, issues 
another read request for future input, and suspends itself. 
As a part of the START procedure, the ground has sent time 
information to the operating system, and the system clock 
has been synchronized. 

• The executive schedules the OUTPUT process to gen- 
erate the ephemeris request and schedules the gyro data 
processing and SENSIN processes. The OUTPUT process is 
scheduled at the proper frequency. It should be noted that 
the SENSIN process is only scheduled when an actual (or 
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simulated) RIU (memory sharing, no interrupts) is used. 
Otherwise, the SENSIN process is interrupt driven. 

• The executive computes star camera occultation from 
ephemeris information. The star data processing processes 
are not invoked if (1) ephemeris data is not available, 

(2) if both star cameras are occulted, or (3) if the atti^ 
tude maneuver flag is on. 

• Under normal circumstances (ephemeris data avail- 
able, no occultation, and no maneuver), the executive will 
schedule the following processes; 

High frequency, high priority SENSIN process 
to collect sensor data and perform some vali- 
dation 

High frequency gyro processing and propagation 
functions to propagate attitude 

OUTPUT process to prepare data annotation re- 
ports 

High frequency star data processing process to 
collect star data, perform data validation, 
and form snapshots. The process is scheduled 
at a high frequency N seconds before the 
scheduled attitude update 

Star identification and attitude update proc- 
esses when star group formation is successful 

OUTPUT process to output update results at the 
update report frequency 

OUTPUT process to generate an ephemeris re- 
quest every 20 minutes 

• Again, all scheduling periods are variable, and can 
be selected from the ground. 
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2.7.3 STAR CAMERA OCCULTATION 


• AADS is running normally scheduling all processes. 
The last process completed was gyro propagation. 

• The executive will check for occultation of the 
star camera's FOV by the Sun, Earth, and Moon. 

• If both star cameras are occulted, the executive 
will schedule star identification and attitude up- 
date if there are enough data for at least one 
star. The attitude will be updated when at least 
one star has been identified depending on the cur- 
rent attitude uncertainty. 

• If both cameras are occulted, and there is no star 
data or if collected star data is not sufficient to 
form a tracker group, the executive will schedule 
the star data processing functions at a later time. 

• The executive will schedule only gyro processing 
functions until such time as at least one star 
tracker is not occulted. A gyro-propagated atti- 
tude will be used for data annotation. 

• The executive will schedule the star processing 
functions as soon as occultation has ended to ob- 
tain an immediate state update. 

2.7.4 ATTITUDE MANEUVER 

• AADS is running normally scheduling all processes. 
The next process to be scheduled is state propaga- 
tion. 

• State propagation will read gyro data, which con- 
tains a bit indicating a high/low gyro mode. If 
the bit value signifies the high-rate mode, then 
the gyro propagation process will set the maneuver 
flag in a global COMMON area. The gyro rates will 
be computed using a different conversion constant. 
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• The executive will check the maneuver flag when the 
gyro propagation process is completed or suspended. 






If the maneuver flag is set, the executive takes 
the following actions: 

- Schedules immediate state update if at least 
one star has been identified; otherwise, sus- 
pends the star processing processes 

- Uses a different (higher) frequency for sched- 
uling gyro processing and gyro propagation 

Continues data annotation with the gyro- 
propagated attitude estimates 

When the maneuver flag is reset by the gyro propa- 
gation process (indicating low-rate mode for 
gyros), then (1) schedule the star processing proc- 
ess immediately to get an attitude update and 
(2) resume gyro processing and propagation with 
normal (lower) frequencies. 


2.7.5 CONTINGENCIES AND ERROR HANDLING 

The following instructions describe how to handle contingen- 
cies and errors. 

2 . 7 . 5 . 1 Minor Errors 

If ; 

• All gyro data are flagged before a gyro propagation 

• A tracker group was rejected during validation 

• A tracker group could not be identified 

Then , 

• Add error messages to the error log 

• Continue processing normally 

There is one error log (OUTBUF) . The executive does not 
schedule the OUTPUT process immediately for minor errors. 
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2. 7. 5. 2 Severe Errors 


If: 

• Several successive failures occur during star 
identification and no stars are identified during a 
specified time period: 

Then, 

• Schedule the OUTPUT process for sending a critical 
error message 

• Suspend star processing; continue gyro processing 
and data annotation with gyro propagation 

• Wait for table modification and a RESUME (resume 
star processing) command from the ground 

If; 

• All gyro data are consistently flagged for a 
specified period: 

Then , 

• Send a critical message to the ground 

• Downlink all sensor raw data from the buffer 

• Halt processing and wait for a table modification 
and START command 

If : 

• There is an arithmetic exception; 

Then , 

• Take a specified (TBD) action (set the result equal 
to 0.0) 

• Send a critical error message to the ground 

• Continue processing 



Ground will probably request software dump from the 
operating system. 


If: 

• There is an addressing exception (attempted 
overwrite) : 

Then » 

• Send a critical error message to the ground 

• Send all raw data to the ground 

• Shut down and wait for a START command 

• The ground will request a software dump 
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SECTION 3 - AADS BASELINE DIAGRAMS 


This section presents detailed baseline diagrams for AADS as 
a whole and for various processes within the system. This 
section also contains processing overviews for and descrip- 
tions of components in the processes. Figure 3-1 describes 
the flowcharting symbols used in the various diagrams. Fig- 
ures 3-2 and 3-3 show the AADS external and internal inter- 
faces, respectively. 

Each of the first nine subsections describes one process in 
AADS. Each subsection describes the input data required for 
processing and the output from the process. A simple figure 
illustrates the input and output. The processing in each 
case is also described and is intended for use with the data 
flow and baseline diagrams. A table contains a description 
of each component in the baseline diagrams. Section 3.10 
describes the AADS star catalog generation utility. 

It should be noted that /STATIC/refers to the four COMMON 
areas /STATl/, /STAT2/, /STAT3/, and /STAT4/ for conven- 
ience. These COMMON areas contain the AADS control param** 
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3 . 1 EXECUTIVE PROCESS 


This section describes the executive (EXEC) process. 

3.1.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the EXEC process. Figure 3-4 illustrates the 
external interfaces. 

3.1.1. 1 Input 

The following items are required as input: 

• Constants and data needed for scheduling 

- Operating system (OS) clock and timer inter- 
rupts 

Process -interval times 
Output frequencies 
Process priorities 

Event flags and process completion interrupts 

- Maneuver flag 
Commands 

. ^ Process return codes and status flags 

• Constants and data needed for occultation prediction 

Ephemeris data 
Occultation constants 
Spacecraft attitude 

3. 1. 1. 2 Output 

The following items are output from the EXEC process: 

• Parameters and operating system requests for 
scheduling 
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OUTPUT 
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EPHEMERIS DATA 
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ATTITUDE 
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MISSION MODE FLAG 
TASK RETURN CODES 
COMMANDS 
SYSTEM STATUS FLAGS 



OS TIMER REQUESTS 
OS TASK RESUMPTION REQUESTS 
PROCESSING PARAMETERS 
ERROR MESSAGES 
REPORT GENERATION REQUESTS 
EPHEMERIS REQUESTS 
ACTIVITY LOG STATISTICS 
SYSTEM STATUS FLAGS 


Figure 3-4. EXEC Process External Interfaces 
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OS timer requests 

- OS process resumption requests 

Input processing parameters and system status 
flags 

• Requests, messages, and reports for output 

- Error messages 
Report-generation requests 
Ephemeris requests 

• Activity log statistics 
3.1.2 PROCESSING 

The EXEC process functions as a miniature operating system 
and schedules various AADS processes as required. The EXEC 
process resumes when a command is received, a timer inter- 
rupt occurs, or one of the other processes completes 
execution. The EXEC process performs requireo executive 
functions at a high priority. 

AADS is initialized and VAX-specific initialization is per- 
formed. Commands are processed. Normal scheduling of 
processes is performed, and the scheduling is changed when 
maneuver or gyro saturation conditions are detected. When 
computations show that both star cameras are occulted, re- 
sumption of the star data processing (STRACK) function is 
delayed . 

Scheduling is modified or other error handling is performed 
in response to process return codes. Attitude information 
for data annotation and reports is output at required 
periods. The ephemeris is checked at the end of a major 
cycle, and a request for more ephemeris data is made when 
insufficient ephemeris data remain for the next major 
cycle. The input data processing (INPUT) function is 
invoked when possible to validate ephemeris that is 
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received, or at the end of a major cycle to validate input 
data. The activity log is maintained. The state update 
cycle is timed, and a critical error message is generated 
when the update time limit is exceeded. 

Table 3-1 contains the descriptions of EXEC process compon- 
ents to be used with Figures 3-5 and 3-6. Figure 3-5 illus 
trates data flow within the process and Figure 3-6 
Illustrates the relationship among process components. 


Table 3-1. EXEC Process Component Descriptions (1 of 2) 


Component 

MAIN 


INITL 

PROCESSES 

FLAGS 
CMDPRO 
TIMED P 

TSKDNE 

ACT LOG 

ENQUE 
BLDLOG 
CANCEL 
UPS TAT 

OCCULT 

SCHED 

TIMOBT 

/EXEC/ 


Description 

Driver for AADS executive process; initializes 
local COMMON variables and calls a subroutine 
to initialize AADS; waits for and tests event 
flags and calls subroutines to direct process- 
ing as needed by time-event, command recep- 
tion, or process completion 

Performs VAX-specific initialization and is 
driver for AADS initialization 

Creates each AADS process (except EXEC) , 
allowing each process to initialize; 
priorities are set in process creation 

Initializes AADS global COMMON areas 

Reads a command from buffer and processes it 

Resumes next scheduled process, updates 
schedule, and resets timer; checks for 
ephemeris data requiring validation 

Sets flags, increments counters, queues re- 
quests for reports, and resumes processes 
based on completion of a process 

Driver for subroutines to maintain activity 
log and to queue requests for reports and 
error messages 

Queues error messages and requests for reports 

' Maintains and updates activity log 

Performs an orderly shutdown of AADS 

Directs state transitions in response to 
START, HALT, and RESUME commands 

Checks for occultation of both star cameras 

Inserts next scheduled time into a table for a 
process and resets timer 

Obtains current simulation time and converts 
it to either seconds from September 1, 1957, 
or YYMMDD.HHMMSSMMM format 

Local COMMON area; which contains flags, 
schedule, and process identification number 
used by AADS executive. 
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Table 3-1. EXEC Process Component Descriptions (2 of 2) 

Component ' : Description ^ 

B8ADD Adds two integer quadwords 

INTERP Performs a six-point interpolation of ephemeris 

OPENGL User open routine for temporary global COMMON 

data sets 
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3.2 SENSOR DATA COLDEGTION PROCESS 


This section describes the sensor data collection (SCNSIN) 
process. 

3.2.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the SENSIN process. Figure 3-7 illustrates the 
external interfaces. 

3. 2. 1.1 Input 

The following items are required as input; 

• Gyro data from six channels 

Gyro counts 
Power-on/off flag 
Low/high-gain (rate) flag 

• Star camera data from two cameras 

- H and V counts 

Star camera temperature 
Star intensity 
Star presence flag 

• Current time in seconds since September 1, 1957, 

0 hours Universal Time (UT) 

3. 2.1. 2 Output 

The following items are output from the SENSIN process; 

• Time-tagged gyro data 

Time in seconds since September 1, 1957, 

0 hours, UT 

Number of observations 
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Figure 3-7. SENSIN Process External Interfaces 



• Time-tagged star camera data 

H and V counts, star camera temperature, and 
star intensity 

- Star presence flag 

Number of observations 

3.2.2 PROCESSING 

The SENSIN process will be nominally invoked every 64 milli- 
seconds to read gyro data and every 100 milliseconds to read 
star camera data. SENSIN will perform minimum required 
processing at a high priority. 

Gyro data are stored in COMMON /SENSOR/ with the current 
time. Star tracker data and the associated time are stored 
in COMMON /SENSOR/ without any decoding. In both cases, the 
counters for gyro and star camera observations are updated. 
The gyro data and star tracker data buffers are used in a 
wraparound manner. That is, SENSIN starts filling data from 
the top of the buffer when the buffer is filled. SENSIN 
maintains the start and end pointers for data arrays. 

GYPROC and STRACK processes use the available data when in- 
voked, and then reset the start pointer for the next cycle. 

The times used for gyro and star camera data may be in error 
by 64 milliseconds and 50 milliseconds (maximum), respec- 
tively. The error in the computed attitude will not in- 
crease significantly because of these time errors. 

Table 3-2 contains the descriptions of SENSIN process com- 
ponents to be used with Figures 3-8 and 3-9. Figure 3-8 
illustrates data flow within the process and Figure 3-9 il- 
lustrates the relationship among process components. 
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Table 3-2. SENS IN Process Component Descriptions 

Component Description 

Driver for high-frequency sensor data 
collection process 

Collects and stores gyro data 

Collects and stores star tracker (FHST) data 

Returns current simulation time in desired 
format 

Adds two quadwords 

User open routine for temporary global COMMON 
areas 

Global COMMON area from which raw sensor data 
is obtained 
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3.3 INPUT PROCESS 


This section describes the input data processing (INPUT) 
function. 

3.3.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the INPUT process. Figure 3-10 illustrates the 
external interfaces. 

3. 3.1.1 Input 

The following items are required as input: 

• Uplink 

Commands: RESUME, HALT, STOP, START, and SET 

CLOCK 

Data to update global COMMON /STATIC/ 

• Spacecraft ephemeris (computed by the onboard com- 
puter) 

3. 3. 1.2 Output 

The following items are output from the INPUT process: 

• Decoded commands for the EXEC process 

• Validated uplinked data stored in global COMMON 
/STATIC/ 

• Validated spacecraft ephemeris 

• Status in global COMMON /GLOBAL/ 

• Error messages in global COMMON /OUTBUF/ 

3.3.2 PROCESSING 

The INPUT process consists of two major subsystems: the 

data capture (DCAP) subsystem and the full input data proc- 
essing (INPUT) subsystem. Each subsystem is called (as a 
subroutine) by the INPUT process driver, DCAPIN. DCAPIN 


r 


INPUT 

COMMANDS 

DATA FOR TABLE UPDATES 
SPACECRAFT EPHEMERIS 


Figure 3-10. 


OUTPUT 


INPUT 





DECODED COMMANDS 

COMMANDS, DATA, EPKEMERIS 
RECEIVED FLAGS 

VALIDATED DATA STORED IN COMMONS 
(TABLE UPDATE) 


VALtOATEO EPHEMERIS 


ERROR flags AND MESSAGES 

W 


INPUT Process External Interfaces 



itself is invoked in one of two ways: (1) when a read oper- 

ation of input data has just been completed or (2) when the 
EXEC process indicates that queued uplink data and/or stored 
ephemeris data must be validated. In both cases, a unique 
event flag will have been set. DCAPIN invokes the DCAP sub- 
system for case 1 and the INPUT subsystem for case 2. 

The purpose of the DCAP subsystem is to handle quickly the 
preliminary validation and processing of input data from the 
main spacecraft computer (sensor data is obtained by the 
SENSIN process) . Primarily, the DCAP subsystem 

• Checks synchronization byte(s) 

• Saves an input command in global COMMON /GLOBAL/ 
for the EXEC process 

• Stores ephemeris data in global COMMON /FLIGHT/ 

• Queues uplinked data for further validation and 
processing later 

The EXEC process is activated when a command is present or 
an error has been detected. 

The INPUT subsystem performs full validation of uplinked 
data and spacecraft ephemeris data. Uplinked data are vali- 
dated according to header information; ephemeris data are 
validated according to computed magnitude constraints. The 
INPUT process finishes its processing of uplinked data by 
storing the data in the global COMMON /STATIC/. Upon com- 
pletion of its processing in all cases, or INPUT process 
reports its status to the EXEC process and activates it be- 
fore completing execution. 

Table 3-3 contains the descriptions of INPUT process compon- 
ents to be used with Figures 3-11 and 3-12. Figure 3-11 
illustrates data flow within the process and Figure 3-12 
illustrates the telationship among process components. 
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Table 

Component 

DCAPIN 

DCAP 

STOEPH 

QLONG 

INPUT 

INEPH 

INPULL 

HEADER 

STCDAT 

/DCAPIP/ 

/MSGBUF/ 


3. INPUT Process Component Descriptions 


Description 

Driver for input data processing function; 
invoked by operating system when commands or 
ephemeris data are received, or invoked by the 
executive at end of a major cycle to complete 
validation of ephemeris data, table 
parameters, and so on 

Driver for data capture subsystem; DCAPIN 
invokes DCAP subsystem when a command or an 
ephemeris read occurs--input is processed with 
minimum, preliminary validation--alerts EXEC 
process immediately about ground commands 

Stores spacecraft ephemeris 

Queues uplinked data in full, 256-byte records 
for later validation 

Driver for input data subsystem; validates and 
stores data acquired by data capture subsystem 

Validates spacecraft ephemeris 

Validates and stores long block (256-byte) 
uplinked data 

Validates record according to header 
information 

Stores control parameters in global COMMON 
/STATIC/ 

Local COMMON area used to queue uplinked data 
for later validation 

Local COMMON area containing buffer into which 
data are initially read 
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Figure 3-11. INPUT Process Data Flow 
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3.4 OUTPUT PROCESS 


This section describes the output data processing (OUTPUT) 
function. 

3.4.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the OUTPUT process. Figure 3-13 illustrates 
the external interfaces. 

3. 4. 1 .1 Input 

The following items are required as input: 

• Annotation data 

Quaternion 

Associated time for quaternion 

• Activity log data' 

Current time 

Time of START command 

- Number of SET CLOCK commands received 

- Total number of state updates attempted 

- Total number of successful state updates 
Total number of spacecraft epheraeris requests 
Total number of gyro data saturations 

Total number of identified stars 

• Raw sensor data 

Gyro data from six channels: gyro counts, 

power-on/off flag, and low/high-gain flag 

Star data from two star cameras: H and V 

poordinate counts, star camera temperature, 
star intensity, power-on/off flag, and star 
presence flag 
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Figure 3-13. OUTPUT Process External Interfaces 



state update data 


- Quaternion 
Associated time 
Gyro drift biases 
Gyro configuration 
State covariance matrix 
Kalman gain matrix 

Time between first and last identified stars 
’ - Number of star vectors formed 

Number of stars identified 

• Spacecraft ephemeris (for inertial-to-orbital coor 
dinate transformation) 

• Report request indicators 

Activity log output request 
Raw sensor data output request 
State update output request M 

Annotation data output request 

• Queue of high-priority, critical error messages 

Pointers for error queues 

• Spacecraft ephemeris request data 

Request indicator 
Start time 
Number of points 

Time interval between points (seconds) 

3 . 4 . 1 . 2 Output 

The following items are output from the OUTPUT process: 

• Annotation report 

- Quaternion 
Euler angles 
Associated time 


• Activity log (formatted report of items detailed in 
Section 3. 4. 1.1) 

• Raw sensor data report (see Section 3.4. 1.1) 

• State update report (see Section 3. 4. 1.1) 

• Critical error messages 

• Spacecraft ephemeris request 
3.4.2 PROCESSING 

The OUTPUT process is activated periodically by the EXEC 
process to output annotated data, the activity log, and 
ephemeris requests. It is. also activated to report errors 
when the other processes indicate errors. The OUTPUT proc- 
ess communicates with the OBC; the OBC transmits AADS com- 
munications to the ground. 

When an annotation data report is to be output, the space- 
craft ephemeris is used to transform the spacecraft attitude 
in quaternion form to the pitch, roll, and yaw. The annota- 
tion report contains both the quaternion and the pitch, 
roll, and yaw angles. 

When critical error messages are present, they are output. 

An ephemeris request is generated and transmitted when re- 
quired. The indicators for the activity log, raw sensor 
data, and state update reports are checked; these reports 
are formatted and output as requested. The OUTPUT process 
activates the EXEC process after completing execution, set- 
ting its status in the status indicator, array (SSTATE) . 

Table 3-4 contains the descriptions of OUTPUT process com- 
ponents to be used with Figures 3-14 and 3-15. Figure 3-14 
illustrates data flow within the process and Figure 3-15 
illustrates the relationship among process components. 
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Table 3-4. OUTPUT Process Component Descriptions 


Component 

OUTPUT 

OBOUT 

HIPRI 

REPORT 

RPY 

RAWDAT 

UPDRPT 

OUTACT 

TIMOBT 


Description 

Drives output data processing function; calls 
subroutines until all requested reports and 
queued messages are transmitted to the OBC 

Sends data annotation reports and spacecraft 
ephemeris requests 

Sends high-priority (critical error) messages 
to ground through the OBC (OSS) 

Formats and sends reports for downlinking via 
OBC (OSS) 

Transforms a quaternion to roll, pitchf and yaw 

Formats and sends raw sensor data report 

Formats and sends update reports 

Formats and sends activity log 

Returns current simulation time in desired 
format 

Adds two quadwords 

Performs a six-point interpolation of ephemeris 
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Figure 3-14. OUTPUT Process Data Flow 
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•UTPUT Process Baseline Diagram 
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3.5 GYRO DATA PROCESS 

This section describes the gyro data processing (GYPROC) 
function. 

3.5.1 INPUT/OUTPUT 

The following subsections describe the input and output pa^ 
rameters for the GYPROC process. Figure 3-16 illustrates 
the external interfaces. 

3 . 5 . 1 . 1 Input 

The following items are required as input: 

• Gyro data from six channels 

Gyro counts 
Power-on/off flag 
Low/high-gain (rate) flag 

• Times associated with the raw gyro data (time in 
seconds since September 1, 1957, 0 hours UT) 

• Pointers to indicate the beginning and end of gyro 
data 

• Control parameters 

Gyro configuration 
Maximum gyro counts 

- Upper/lower limits for gyro counts 

• Conversion factors to convert gyro counts to angle 

• Gyro alignment matrices for all possible channel 
combinations 

• Flag set by the EXEC process to indicate initiali- 
zation or a normal processing mode 
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Figure 3-16. GYPROC Process External Interfaces 
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3. 5. 1.2 Output 

The following items are output from the GYPROC process: 

• Incremental angles for all channels that are on 

• Incremental times for all channels that are on 

• Maneuver indicator 

• Error messages 

3.5.2 PROCESSING 

The GYPROC process is nominally invoked every 512 millisec- 
onds to validate gyro data and to compute gyro incremental 
angles. It processes the data collected since the last time 
it was invoked. The time period to invoke the GYPROC proc- 
ess can be varied by ground command, but the upper and lower 
limits on the period are expected to be 1,024 milliseconds 
and 256 milliseconds, respectively. 

The GYPROC process performs initialization depending on the 
flag set by the EXEC process. Power-on/off flags, low/high- 
rate flags, and gyro counts are extracted from the gyro 
data. Primary and secondary gyro channels are selected 
based on the gyro configuration specified. The raw data are 
validated for rollover, saturation, and successive differ- 
ence tolerances. Error flags are set if the data fails 
validation checks. Gyro incremental angles and incremental 
times are computed for both primary and secondary configura- 
tions. They are stored in the global COMMON area /SENSOR/ 
for eventual use by the state propagation (PROPAG) process. 
Data pointers are updated in global COMMON /SENSOR/ to 
indicate that the data has been processed by GYPROC. 

The GYPROC process sets the maneuver indicator for the proc- 
esses following GYPROC execution when the rate mode flag in- 
dicates that the gyros are in the high-rate mode. When the 
spacecraft is being maneuvered, the GYPROC process may be 
automatically executed at a higher frequency to limit the 
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error in attitude computation. Since the star data process 
ing functions are not invoked during spacecraft maneuvers, 
higher execution frequency is possible. 

Table 3-5 contains the descriptions of GYPROC process com- 
ponents to be used with Figures 3-17 and 3-18. Figure 3-17 
illustrates data flow within the process and Figure 3-18 
illustrates the relationship among process components. 



Table 

Component 

GYPROC 

GYROED 

CHECK 

GYROUT 

SELECT 

HEAD 

MESS 

TCON21 

DAT VAX 

/PROC/ 


5. GYPROC Process Component Descriptions 


Description 


Driver for gyro data processing function 

Gyro data validation driver; checks for 
spacecraft maneuver by change in gyro rate flag 

Checks for rollover, saturation, and glitches 
in gyro data 

Converts gyro counts to angles; stores sums of 
incremental angles and times for all channels 

Selects primary and backup gyro channel 
combination from the gyro configurations 
indicator and selects corresponding alignment 
matrices 

Stores error number and current time in output 
buffer queue 

Stores error message in output buffer queue 

Converts time from seconds since September 1, 
1957, to calendar format ( YYMMDD.HHMMSS) 

Computes calendar date corresponding to a 
given Julian day 

Local COMMON area 
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Figure 3-17. GYPROC Process Data Flow 
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3.6 STATE PROPAGATION PROCESS 


This section describes the state propagation (PROPAG) proc 
ess. 

3.6.1 INPUT/OUTPUT 


The following subsections describe the input and output pa 
rameters for the PROPAG process. Figure 3-19 illustrates 
the external interfaces. 

3. 6. 1.1 Input 

The following items are required as input; 

• Gyro configuration number 


• Alignment matrices for all gyro configurations 

• Incremental angles and times for all six channels 

• Gyro biases (drift rates) 

• Tolerances for redundancy between primary and 
backup channel combinations 

• Quaternion and state covariance matrix 

• Gyro rate noise (float torque) and gyro rate-rate 
noise (ramp noise) 

• Flag set by the EXEC process to indicate inltiali 
zation or normal processing mode 


3.6.1. 2 Output 

The following items are output from the PROPAG process: 

• Propagated quaternion 

• Propagated state covariance matrix 

• Spacecraft angular velocity vector in the space 

craft frame 
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Figure 3-19. PROPAG Process External Interfaces 



• GCI to spacecraft transformation matrix 

• Error messages 
3.6.2 PROCESSING 

The PROPAG process is invoked after the GYPROC process is 
invoked N times; N is set by ground command and is nominally 
set to 1. Thus, PROPAG propagates the quaternion and the 
state covariance matrix nominally every 512 milliseconds. 

Body rates in the gyro coordinate frame are computed from 
the valid incremental angles and the incremental times for 
both the primary and backup channels. PROPAG then performs 
a redundancy test to check the rate differences between the 
primary and backup channels and sets appropriate error flags 
if the validation check fails. 

The gyro rates are rotated from the gyro coordinate frame to 
the spacecraft (body) coordinate frame. Drift biases are 
eliminated. These body rates and the propagation time in- 
terval are used to compute the body rotation matrix, state 
transition matrix, and the covariance transition matrix. 

The process noise matrix (consisting of the gyro noise vari- 
ances) , the body rotation matrix, and the propagation time 
interval are used to compute the noise covariance matrix. 

The spacecraft attitude (in the quaternion form) is propa- 
gated by using the current quaternion and the state transi- 
tion matrix. The state covariance matrix is propagated by 
using the current state covariance matrix, state covariance 
transition matrix, and noise covariance matrix. The propa- 
gated quaternion and the state covariance matrix are saved 
in global COMMON /STATE/. PROPAG propagates the quaternion 
pa^rt of the state vector and does not propagate the gyro 
biases in the state vector. 
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Table 3-6 contains the descriptions of PROPAG process com- 
ponents to be used with Figures 3-20 and 3-21. Figure 3-20 
illustrates data flow within the process and Figure 3-21 
illustrates the relationship among process components. 
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Table 3-6. PROPAG Process Component Descriptions 


Component 


Description 


PROPAG 

BRATE 

PRINTR 


QPROP 

COPROP 


PROPIN 

/PROPG/ 

SGMPRD 

SGMTRA 

SDIAG 

SMTADD 

SMLMAT 

SDTPRD 

SCOPY 

SNULLA 

HEAD 

ME$S 

TCON21 

DATVAX 


Driver for state propagation process 

Eliminates gyro biases and computes body-rate 
vector and body-rotation skew symmetric matrix 

Computes state transition matrix (3x3) for 
three-quaternion propagation; computes state 
covariance transition matrix and noise 
covariance matrix 

Uses current quaternion and state transition 
matrix to propagate quaternion 

Uses current state covariance matrix, state 
covariance transition matrix, and noise 
covariance matrix to propagate state 
covariance matrix 

Initializes PROPAG process 


Local COMMON area 

Computes product of two matrices 

Computes transpose of the matrix 

Computes sum of square matrix and identity 

matrix 


Computes sum of two matrices 

Computes product of a scalar and matrix 

Computes dot product of two vectors 

Copies one two-dimensional area to other 
two-dimensional areas 

Stores zero in all elements of a matrix 

Stores error number and current time in error 
buffer 

Stores error message in error buffer 

Converts time in seconds since September 1, 
1957, to calendar format (YYMMDD.HHMMSS) 

Computes calendar date corresponding to a 
given Julian day 
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Figure 3-20. PROPAG Process Data Flow 
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Figure 3-21. PROPAG Process Baseline Diagram 
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3.7 STAR DATA PROCESS 


This section describes the star data processing (STRACK) 
function. 

3.7.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the STRACK process. Figure 3-22 illustrates 
the external interfaces. 

3. 7. 1.1 Input 

The following items are required as input: 

• Raw star tracker data 

H and V counts 
Times 

Star intensity (counts) 

Star tracker temperature (counts) 

Star presence flag 

Star tracker power-on/off flag 

• Fresh raw data location indicators 

• Invalid data timespan tolerance parameters 

• H, V, intensity, and temperature editing parameters 

• H and V calibration parameters to correct for in- 
tensity and temperature effects 

• H, V, intensity, and temperature conversion param- 
eters 

• Track point grouping parameters 

• GCI to spacecraft transformation matrices 

• Star tracker alignment matrices 

• Spacecraft angular velocity vectors in the body 
frame and times 

• Attitude quaternions and times 
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Figure 3-22. STRACK Process External Interfaces 
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• Intensity-to-magnitude conversion parameters 

• Minimum number of groups necessary before attempt- 
ing star identification 

• Current attitude uncertainty and attitude uncer- 
tainty criterion for selecting star identification 
method 

• Flag set by the EXEC process to indicate initiali- 
zation or a normal processing mode 

3.7.1. 2 Output 

The following items are output from the STRACK process; 

• Track point group average data 

Times 

Unit vectors in geocentric inertial (GCI) co- 
ordinate frame 

Number of track points in each group average 
Star magnitudes 

• Error messages 

• Flag to indicate sufficient tracker groups to at- 
tempt star identification 

3.7.2 PROCESSING 

The STRACK process uses raw star tracker data prepared by 
the SENS IN process. It acquires all the fresh raw star 
tracker data according to fresh data pointers. The pointers 
are updated at the end of processing to reflect the current 
status of stored raw data. 

Each raw star tracker data sample includes data time, H and 
V counts, star tracker temperature, star intensity, star 
presence flag, and star tracker power-on/off flag. Data 
samples with flags that indicate power on and star presence 
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are subjected to limit checking. Temperature and intensity 
ate converted from counts to volts before being checked. 

Data samples with flags that indicate power off and no star 
presence, or that fail limit checking are considered invalid 
and are discarded. A warning message is issued when consec- 
utive invalid data timespans exceed a tolerance. 

Validated data are then separated into groups. Presumably, 
each group contains tracking data from a single star. The 
group-forming criteria include the maximum difference be- 
tween two consecutive H and V counts, maximum and minimum 
number of tracking points in a group, maximum group time 
duration, and minimum time separation between two groups. H 
and V counts are calibrated for temperature and intensity 
effects and are converted into angles. 

The next step is to compute track point unit vectors and to 
perform group averages. The track point unit vectors in the 
current tracker coordinate frame are computed from H and V 
angles. They are rotated to the tracker coordinate frame at 
the nearest gyro-rate times and then to the GCI coordinate 
frame using gyro-propagated attitude at the gyro-rate 
times. Track point unit vectors in the GCI coordinate frame 
and corresponding star intensities in each group are aver- 
aged. The group clump sizes are then computed. The 
averaged star intensities are converted to magnitudes. 

If the number of track points used in a group average exceed 
minimum requirements and the group clump size is within tol- 
erance, the group is considered acceptable for star identi- 
fication. Current attitude uncertainty is computed from the 
first three diagonal elements of the state covariance ma- 
trix. The attitude uncertainty determines the number of 
groups required to be formed before attempting star iden- 
tification and the star identification method to be used. 
When the number of the acceptable groups satisfies minimum 
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requirements for the identification method selected, a flag 
is set to inform the EXEC to invoke the star identification 
(STARID) process. 

Table 3-7 contains the descriptions of STRACK process com- 
ponents to be used with Figures 3-23 and 3-24. Figure 3-23 
illustrates data flow within the process and Figure 3-24 
illustrates the relationship among process components. 



Table 

Component 

S TRACK 
INITST 

STREAD 

MAGN 

TGROUP 

CALIB 

SYNVEC 


SGMPRD 

AVGVEC 


FCALIB 

TCON21 

ANGLED 

UNVEC 

PATVAX 

/TRACK/ 


7. STRACK Process Component Descriptions 


Description 

Driver of star data processing function 

Initializes star tracker data processing 
working parameters 

Edits raw star tracker data, forms track 
group, and calibrates raw data 

Edits star tracker data 

Forms track group 

Driver to calibrate raw star track data for 
temperature and intensity correction 

Computes the track point unit vector; syn- 
chronizes unit vector to nearest 
gyro-propagated quaternion time; rotates unit 
vector to GCI coordinate frame 

Multiplies two matrices. 

Computes average of track point unit vectors 
in a track group; determines star 
identification method and sets a flag when 
there are enough groups to attempt star 
identification 

Calibrates raw star tracker data for 
temperature and intensity correction 

Converts time in seconds from September 1, 
1957, to the calendar format (YYMMDD.HHMMSS) 

Computes angle between two unit vectors 

Unitizes a vector 

Computes calendar date corresponding to a 
given Julian day 

Local COMMON area 
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Figure 3-23. STRACK Process Data Flow 


























3.8 STAR IDENTIFICATION PROCESS 


This section describes the star identification (STARID) 
process. 

3.8.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the STARID process. Figure 3-25 illustrates 
the external interfaces. 


3. 8.1.1 Input 

The following items are required as input: 

• Track point group average data 

Times 

Unit vectors in the GCI coordinate frame 
Number of track points in each group average 
Star magnitudes 

Earth ephemeris 

Solar ephemeris computation parameters 
Star catalog and star catalog search parameters 
Star identification parameters 

Flag set by the EXEC process to indicate initiali- 
zation or a normal processing mode 

3. 8. 1.2 Output 

The following items are output from the STARID process: 

• Averaged star data corrected for stellar aberration 

Unit vectors in the GCI coordinate frame 
Number of track points in each group (average) 
Star magnitudes 
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TIME TAGGED OBSERVED STARS AS UNIT 
VECTORS IN GCI FRAME 

ONBOARD STAR CATALOG 

SOLAR CONSTANTS 
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CORRESPONDING CATALOG STARS 
STAR IDENTIFICATION RESULT FLAG 




Figure 3-25. STARID Process External Interfaces 


• Catalog star data (corrected £or precession and 
nutation) 

Unit vectors in the GCI coordinate frame 

Star magnitudes 

Star identification numbers 

• Flag to indicate success or failure of star identi 
fication process 

3.8.2 PROCESSING 

The STARID process matches the observed star vectors with 
star vectors given in a star catalog. The observed star 
unit vectors are corrected for the stellar aberration 
effect. The spacecract velocities with respect to the Sun 
are calculated for this purpose. The observed stars are 
temporarily rotated to the epoch time (year 2000) of the 
AADS star catalog during the search for candidate stars. 

The star catalog is searched to find candidate stars that 
fall within a certain range of the observed star positions 
and that have comparable magnitudes depending on the toler- 
ances. The observed stars for which candidate stars have 
not been found are flagged. Those with one or more candi- 
date stars are identified using direct matching or pairwise 
matching techniques. If star identification is successful, 
then the resulting candidate stars are rotated to the cur- 
rent time from year 2000 (star catalog epoch time) . The ob- 
served stars that are successfully identified will be used 
in the UPDATE process to update the state vector. 

Table 3-8 contains the descriptions of STARID process com- 
ponents to be used with Figures 3-26 and 3-27. Figure 3-26 
illustrates data flow within the process and Figure 3-27 
illustrates the relationship among process components. 
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Table 

Component 

STARID 

INITID 

ABER 

SMPOS 

CATLG 

PRENUT 

SUBCAT 

DESTAR 

ANGLED 
/IDS TAR/ 

I DENT 
I DENT 1 

IDENT2 

PAIR2 

INTER? 

RADECM 

VEC 


1>8. STARID Process Component Description 


Descr iption 

Driver for star identification process 

Initializes star identification working param- 
eters 

Corrects star unit vector in inertial coordi- 
nate frame for stellar aberration 

Computes solar ephemeris 

Driver to perform star catalog search for can- 
didate stars 

Gives precessienal and nutational correction 
for star position 

Gives starting location and number of stars in 
a star subcatalog 

Decodes a star catalog entry to give right as- 
cension and declination angles and star magni- 
tude 

Gives angle between two vectors 

Local COMMON area 

Subdriver for star identification 

Identifies observed stars using direct match- 
ing method 

Identifies observed stars using pairwise 
matching method 

Identifies remaining observed stars using a 
pairwise matching method after a pair of stars 
has been identified 

Interpolates Earth ephemeris for the current 
time 

Computes right ascension, declination, and 
magnitude for a given vector 

Computes unit vector from right ascension and 
declination 
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Figure 3-26. STARID Process Data Flow 





Figure 3-27. STARID Process Baseline ID 
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3.9 STATE UPDATE PROCESS 


This section describes the state update (UPDATE) process. 

3.9.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the UPDATE process. Figure 3-28 illustrates 
the external interfaces. 

3 . 9 . 1 . 1 Input 

The following items are required as input: 

• Averaged observed star data 

- Unit vectors in the GCI coordinate frame 
Number of track points in each average 
Clump size of the group 

• Catalog star unit vector in the GCI coordinate frame 

• Observation noise 

• GCI to body transformation and star tracker align- 
ment matrices 

• Current state vector 

• Current covariance matrix 

• Input parameters set by the EXEC process for ini- 
tialization on nominal processing 

3.9. 1.2 Output 

The following items are output from the UPDATE process: 

• Updated state vector 

• Updated state covariance matrix 

3.9.2 PROCESSING 

The UPDATE process uses a least-squares algorithm to mini- 
mize the distances between observed and predicted star posi- 
tions; in the process, it updates the gyro-propagated state 
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INPUT 

A PRIORI STATE VECTOR 

A PRIORI COVARIANCE MATRIX 

OBSERVED STAR UNIT VECTOR AND COR- 
RESPONDING CATALOG STAR UNIT VECTORS 

SPACECRAFT BODY TO TRACKER MATRICES 

MODEL MEASUREMENT NOISE 

GCI TO BODY TRANSFORMATION MATRIX 



OUTPUT 

UPDATED STATE VECTOR 
DRIFT BIASES IN BODY FRAME 
UPDATED STATE COVARIANCE MATRIX 
DRIFT BIASES IN GYRO FRAME 
KALMAN GAIN MATRIX 


Figure 3-28. UPDATE Process External Interfaces 
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vector that contains the spacecraft attitude quaternion and 
gyro drift biases. 

The observed star unit vectors in the GCI coordinate frame 
ace rotated into a tracker coordinate frame at the current 
gyro-propagated attitude. The model observations are com- 
puted from unit vectors in the tracker coordinate frame. 

The observation noise is computed, using the maximum of the 
model noise and the group clump size. The model predictions 
are computed using catalog star unit vectors and the current 
gyro-propagated attitude. Observation residuals and the 
partials are computed. A least-squares algorithm is used to 
minimize the differences between observed and predicted 
values (observation residuals) and to compute corrections to 
the gyro-propagated state vector and covariance matrix. 
Finally, the state vector is updated with the quaternion 
part renormalized. 

Table 3-9 contains the descriptions of UPDATE process com- 
ponents to be used with Figure 3~29 and 3-30. Figure 3-29 
illustrates data flow within the process and Figure 3-30 
illustrates the relationship among process components. 
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Table 3-9. UPDATE Process Component Descriptions 


Component 

UPDATE 

INITUP 

KALMAN 

PARTL 

PROBVC 

RECUR 

SGMPRD 

/UPDAT/ 


Description 

Driver for state update process 

Initializes state vector, state covariance 
matrix, and differential state vector 

Driver for Kalman filter algorithm 

Computes measurement partials 

Computes predicted observation vector in body 
coordinate frame using the star reference vec- 
tor and a priori attitude 

Computes gain matrix, correction to state vec- 
tor, and covariance matrix using a recursive 
estimation algorithm 

Matrix product routine 

Local COMMON area 
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_ 

KALMAN 


OJ 


INPUT INTERMEDIATE OUTPUT 

UPDATED STATE (QUATERNION AND DRIFT 
RATE BIASES) 

UPDATES COVARIANCE MATRIX 

Figure 3-29. UPDATE Process Data Flow 


CURRENT STATE VECTOR 
COVARIANCE MATRIX 
OBSERVED STARS IN GCI FRAME 
CATALOG STARS IN GCI FRAME 
DRIFT RATE BIASES 
MEASUREMENT NOISE 


OBSERVED AND CATALOG STARS IN THE 
TRACKER FRAME 

OBSERVATION RESIDUALS 
PARTIALS 

CORRECTION TO THE STATE 
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3.10 AADS STAR CATALOG GENERATION UTILITY (CATGEN) 

This section describes the generation of the AADS star cata- 
log that is used during star identification. The AADS star 
catalog is a subset of the main SKYMAP star catalog (Refer- 
ence 16) , and contains stars with visual magnitude in the 
range 2.0 to 6.5. The star right ascension and declination 
angles are stored with an accuracy of 0.00005 degree or 
0.18 arc-second. The visual magnitudes are stored with an 
accuracy of 0.05. The AADs star catalog contains approxi- 
mately 8700 stars and requires approximately 52 kilobytes of 
memory space. Further information about the structure of 
the star catalog is available in the file [AADS. STAR] CATADS. 
FOR and in Section 4.2.2. 

3.10.1 INPUT/OUTPUT 

The following subsections describe the input and output pa- 
rameters for the CATGEN utility. Figure 3-31 illustrates 
the external interfaces. 

3.10.1.1 Input 

The following items are required as input: 

• SKYMAP star catalog information for each star 

SKYMAP identification number 

Right ascension and declination angles and 
unit star vector in the GCI frame (star posi- 
tion is for epoch 2,000) 

Visual (V) magnitude 

Multistar flag 

- B magnitude 

U magnitude 

• Visual magnitude range to select the stars for the 
AADS star catalog 
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INPUT 

SKYMAP STAR CATALOG CONTAINING 
FOLLOWING INFORMATION ABOUT EACH 
STAR 

- SKYMAP IDENTIFICATION NUMBER 

- RIGHT ASCENSION AND DECLINATION 
ANGLES 

- UNIT STAR VECTOR IN THE GCI FRAME 

- VISUAL (V) MAGNITUDE 

- MULTISTAR FLAG 

- B MAGNITUDE 

- U MAGNITUDE 

VISUAL MAGNITUDE RANGE FOR SELECTING 
AADS STARS 



OUTPUT 

AADS STAR CATALOG CONTAINING ALL 
STARS IN THE SPECIFIED VISUAL MAGNITUDE 
RANGE 

THE IFORMATION ABOUT EACH STAR IS IDEN- 
TICAL TO THAT IN THE SKYMAP STAR 
CATALOG 

NUMBER OF STARS SELECTED 


Figure 3-31, CATGEN Utility External Interfaces 
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The following items are required as output: 

• All SKYMAP stars that fall in specified visual mag- 
nitude range 

• SKYMAP star catalog information 

SKYMAP identification number 

Right ascension and declination angles and 
unit star vector in the GCI frame (star posi- 
tion is for epoch 2,000) 

Visual (V) magnitude 

Multistar flag 

B magnitude 

U magnitude 

• Number of stars selected 
3.10.2 PROCESSING 

The CATGEN utility comprises four separate standalone pro- 
grams. The SKYMAP star catalog is stored on several tapes 
accessible from the IBM S/360-95 in Building 3 at Goddard 
Space Flight Center (GSFC) . The SKYCAT program executes on 
the IBM S/360-95. SKYCAT reads the SKYMAP catalog and se- 
lects the stars that fall in the specified visual magnitude 
range. Pertinent information about each selected star is 
written to an output tape. This tape is carried to Build- 
ing 23 at GSFC. The program IBMVAX executes on the 
VAX-11/780 computer to read this tape, which is in the IBM 
internal format, and converts it to the VAX internal for- 
mat. See Guide for Converting Software From System 360 to 
VAX 11/780 by J. Watson of NASA/GSFC (April 1981) for fur- 
ther information about the internal formats used by the two 
computers and the conversion procedures. The program IBMVAX 



reads each star entry on the input tape, performs the con- 
version from IBM to the VAX internal format, and writes the 
output to a data set MATCAT.DAT on the VAX-11/780. Next, 
program SORT reads all star entries in the data set MATCAT. 
DAT and sorts all entries in terms of ascending right ascen- 
sion angles. The sorted output is written to a data set 
SORTED. SAV. 

Finally, the AADS star catalog is created when the STARID 
process is invoked for the first time during AADS execu- 
tion. As part of the initialization, STARID calls subrou- 
tine CATADS. CATADS reads the star data from data set 
SORTED. SAV, encodes the right ascension and declination 
angles and the visual star magnitude information for each 
star, and stores the information in a COMMON area /CATLOG/. 
The STARID process calls routines SUBCAT and DESTAR, which 
decode star information from the star catalog and return the 
right ascension and declination angles and the visual magni- 
tude. 

When AADS is implemented on the target microcomputer, it may 
be desirable to use an initialized COMMON area /CATLOG/ in- 
stead of re-creating the star catalog in /CATLOG/ each time 
AADS is started. In this case, the routine CATADS will have 
to be modified to save the AADS star catalog after it is 
created. The AADS star catalog will be saved as an object 
module CATLOG$DATA.OBJ, which will be used during the link 
step to create the executable image for the STARID process. 

Table 3-10 contains the descriptions of CATGEN utility com- 
ponents to be used with Figures 3-32 and 3-33. Figure 3-32 
illustrates the data flow within the utility and Figure 3-33 
illustrates the relationship among components. The star 
identification process STARID shown in these figures is not 
a part of the CATGEN utility. STARID uses the star catalog 
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Table 

Component 

SKYCAT 

IBMVAX 

FTIO 

SET_UP 

CONVERT 

SORT 

STARID 

/CATLOG/ 

CATADS 

SUBCAT 

DESTAR 


10. CATGEN Utility Component Descriptions 


Description 


Main routine reads the SKYMAP star catalog on 
IBM S/360-95 and outputs information for se- 
lected stars in specified visual magnitude 
range to a tape 

Main routine converts the tape in the IBM in- 
ternal format to the 7AX-11/780 internal format 

Input/output routines to mount a tape, read 
from a tape data set, and so forth 

Subroutine sets up output buffer used to store 
output in VAX internal format 

Converts single variables from IBM to VAX in- 
ternal format 

Main routine reads data set created by IBMVAX 
and sorts stars in ascending order of right 
ascension angles 

AADS star identification process; calls rou- 
tine CATADS to create AADS star catalog during 
initialization; calls routines SUBCAT and 
DESTAR to decode star information in star 
catalog 

The COMMON area which contains the AADs star 
catalog 

Reads direct access, sorted data set created 
by SORT, encodes star information, and creates 
AADS star catalog 

Subroutine locates starting address of a given 
subcatalog and determines number of stars in 
that subcatalog 

Subroutine decodes a single star entry and 
returns star right ascension and declination 
angles, and visual magnitude 
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SKYMAP CATALOG AADS SUBSET , AADS SUBSET AADS SUBSET. AADS 

IN IBM FORMAT ■ VAX FORMAT SORTED, DIRECT STAR CATALOG 

SEQUENTIAL DATA SET ACCESS DATA SET 


1. SKYMAP NU M B ER 

2. RIGHT ASCENSION. DECLINATION 
ANGLES 

3. STAR UNIT VECTOR IN GCI 

4 . VISUAL IV) MAGNITUDE 

5. MULTISTAR FLAG 

6. B. U MAGNITUDE 


A STARTING LOCATION OF A GIVEN 
SUBCATALOG 

B. NUMBER OF STARS IN A GIVEN 
SUBCATALOG 

C. ENCODED STAR INFORMATION (2. 
4. 5 ENCODED) 

D. DECODED STAR INFORMATION (2, 
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Figure 3-32. CATGEN Utility Data Flow 
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created by CATGEN utility and is shown here to demonstrate 
the use of CATADS, DESTAR, and SUBCAT routines during star 
identification. 



SECTION 4 - REQUIREMENTS FOR EXECUTION 


4.1 GENERAL INFORMATION 

AADS runs on the VAX-11/780 computer or runs in a VAX- 
Intel 8086 system configuration. In both cases AADS runs in 
real time and is supported by the AADS simulator residing on 
the VAX computer. 

AADS runs under the VAX/VMS operating system on the VAX com- 
puter and under a custom-made operating system (References 3 
and 10) on the Intel computer. The operating system pro- 
vides timing services and interrupts; multiprocessing capa- 
bility; data management and input/output services; and error 
recovery at system level. AADS also operates under a system 
executive (EXEC)/ which works as a mini-operating system 
that interfaces with the main operating system. EXEC deter- 
mines schedules for subprocesses, control of execution se- 
quence, and handling of specific AADS contingencies and 
error conditions. 

The operator interfaces with AADS via the ground support 
simulator (GSS) , which resides on the VAX computer. The 
system startup procedure includes allocation of resources 
and assignment of input/output devices. Next, the AADS sim- 
ulator processes (GSS, SDS, and OSS) are activated and the 
system executive in AADS is activated, which, in turn, ac- 
tivates other processes in AADS at appropriate times. This 
complex sequence of events forms a digital command language 
(DCL) procedure that should be used during the startup to 
eliminate setup errors. 

AADS runs in real time and uses a memory region size of ap- 
proximately 200 kilobytes when all system capabilities are 
exercised. AADS needs a cathode ray tube (CRT) , disk space 
and a line printer in the minimum system configuration. The 
simulator data segments used for AADS testing are normally 
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stored on disk data sets, but the segments must be stored on 
tape data sets when the span of data exceeds 4 to 8 hours. 

In this case, a tape drive is required for AADS testing. 

The analyst must be able to initiate system execution {allo- 
cation of resources, assignment of devices, and use of DCL 
procedures) , and must be familiar with the commands and con- 
trol parameters that control AADS execution. These commands 
and the control parameters are available for operator selec- 
tion on menu and parameter displays shown by GSS. GSS also 
receives various reports and messages from AADS and prints 
or displays these reports for review by the analyst. Be- 
sides the analyst, the operator and the maintenance pro- 
grammer must be familiar with system execution requirements 
and other computer resources. 

Section 4.2 describes computer resources and Section 4.3 
describes generation and execution of AADS and other asso- 
ciated systems. Sections 4.4 and 4.5 describe AADS control 
parameters and error messages, respectively. 

4.2 RESOURCES 

AADS system generation and execution require resources in 
the following situations; 

• Both AADS and the AADS simulator on the VAX computer 

• AADS on an Intel 8086 and the AADS simulator on VAX 

• AADS on an Intel microcomputer onboard a spacecraft 

During initial development, both AADS and the AADS simulator 
reside on the VAX computer in the form of executable 
images. There is no overlay requirement and the VAX/VMS 
operating system controls the VAX memory space by paging in 
and out the image segments that are required for execution 
at a given time. AADS requires approximately 200 kilobytes 
of memory space. A CRT, a line printer, or a hardcopy ter- 
minal is the required resource for a typical test run. 
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Various reports generated by AADS and any optional diag- 
nostic test output is usually routed to disk data sets for 
later hardcopy printing and review. 

System services required for AADS execution are briefly de- 
scribed here. For additional information, see Reference 15. 

VAX/VMS user privileges required for execution of AADS and 
the AADS simulator follow. 


Privilege 

Description 


GRPNAM 

Inserting a name in group logical 
name table 


GROUP 

Controlling other processes in same 
group 


ALTPRI 

Altering execution priority values 
for processes 


TMPMBX 

Creating temporary mailbox 


NETMBX 

Creating network device 


The following is 

a list of quota values used during AADS 

system testing. 



Quota 

Description 

Value 

PQL$_ASTLM 

AST limit 

50 

PQL$_BIOLM 

Buffered input/output limit 

50 

PQL$_BYTLM 

Buffered input/output byte count 

128,000 

PQL$_DIOLM 

Direct input/output 

50 

PQL$_FILLM 

Open file 

200 

PQL$_PGFLQUOTA 

Paging file 

20,000 

PQL$_PRCLM 

Subprocess 

80 

PQL$_TQELM 

Timer queue entry 

80 

PQL$_WSDEFAULT 

Default working set size 

300 

PQL$_WSQUOTA 

Working set size 

300 
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The following VAX/VMS system services are used by the AADS. 


Name 


Description 


SYS$_ASSIGN 

SYS$_CLREF 

SYS$_CREPRC 

SYS$_GETTIM 

SYS$_HIBER 

SYS$__NUIVITIM 

SYS$__QIO 

SYS$__READEF 

SYS$_SETIMR 

SYS$_CANTIM 

SYS$_SETPRI 

SYS$_WAITFR 

SYS$__WAKE 

SYS$_WFLOR 

SYS$_ASCEFC 

SYS$_CRMPSC 

SYS$_MGBLSC 

SYS$ TRNLOG 


Assigning input/output channel 
Clearing event flag 

Creating process (start process execution) 
Getting time in 64-bit format 
Hibernating 

Converting binary time to numeric time 

Queuing input/output request 

Reading event flags 

Setting timer 

Canceling timer 

Setting priority 

Waiting for single event flag 

Waking up hibernating process 

Waiting for logical OR of event flags 

Associating common event flag cluster 

Creating and mapping section 

Mapping global section 

Translating logical name 


NOTE ; The last four system services are not used when AADS 
executes on the Intel computer. 


In addition/ the VAX FORTRAN library routines SECNDS and 
IDATE are used. AADS uses the event flag cluster that con- 
tains event flags event flag numbers 64 through 95/ with the 
name 'AADS'. The following is a list of the event flags and 
their purposes. 


Event Flag 

Referencing 


Number 

Processes 

Purpose 

64 

DCAPIN/ EXEC 

Notification of command received 

65 

DCAPIN/ EXEC 

Notification of DCAPIN error 
condition 

66 

DCAPIN, EXEC 

Resumption of uplink data or 
ephemeris data validation 
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Event Flag 
Number 

Referencing 

Processes 

Purpose 

67 

DCAPIN, 

EXEC 

Notification of completion of 
uplink data or ephemeris data 
validation 

68 

SENSIN, 

EXEC 

Notification of SENSIN process 
completion 

70 

GYPROC, 

EXEC 

Notification of GYPROC process 
completion 

72 

PROPAG, 

EXEC 

Notification of PROPAG process 
completion 

74 

STRACK , 

EXEC 

Notification of STRACK process 
completion 

76 

STARID, 

EXEC 

Notification of STARID process 
completion 

78 

UPDATE , 

EXEC 

Notification of UPDATE process 
completion 

80 

OUTPUT, 

EXEC 

Notification of OUTPUT process • 
completion 

82 

EXEC 


Timer event flag 

84 

DCAPIN 


QIO read event flag 

86 

SENSIN 


/RIU/ access synchronization 

AADS uses several COMMON areas during execution. COMMON 

areas STATl, 

STAT2, 

STAT3, 

and STAT4 contain AADS control 

parameters. 

COMMON 

areas 

FLIGHT, GLOBAL, SENSOR, and STATE 

are used by 

AADS processes 

for interprocess communication. 


These COMMON areas are contained in a global section named 
•AADS-COMMON' . 

The COMMON area /ADSGBL/, from which the simulation time 
offset is obtained, is contained in the global section named 
'ADSGBL'. EXEC is the only process of AADS to reference 
this global section. The COMMON area /RIU/, from which the 
raw sensor data are obtained, is contained in the global 
section name 'RIU'. SENSIN is the only process of AADS to 
reference this global section. 
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The following is a list of the process priorities used dur- 
ing AADS system testing. 

Process Priority 


DCAPIN 
SENSIN 
GYPROC 
PROPAG 
STRACK 
STAR ID 
UPDATE 
OUTPUT 
EXEC 


15 

14 

10 

10 

6 

6 

6 

8 

12 


Mailboxes are used to accomplish the input/output between 
AADS and the AADS simulator. The logical names of these 
mailboxes are as follows. 


Mailbox 
Logical Name 


Function 


UPLINK 

DNLINK 


Uplink data from OSS to AADS 
Downlink data from AADS to OSS 


AADS will be transferred to the Intel 8086 computer during 
the final stage of AADS prototype development. The AADS 
Simulator will still reside on the VAX computer. In addi- 
tion, the Intel executable version of AADS source will be 
created on an Intel development system (Reference 18) and 
will be stored in a disk data set on the VAX computer. The 
executable images will be transferred into the Intel memory 
before execution because the Intel computer (the final tar- 
get computer) will not have any peripheral devices for stor- 
age. All AADS process images, the AADS star catalog, the 
new Intel operating system (Reference 10) , and the mathe- 
matical library will reside in the Intel memory. The cur- 
rent estimates indicate that AADS will require approximately 
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315 kilobytes. These are conservative estimates and assume 
an expansion factor of 2.0 for the object code between the 
FORTRAN compilers for the VAX and the Intel computers. 

AADS execution in the VAX- Intel configuration requires the 
resources mentioned for the VAX computer, except the SYS$__ 
ASCEFC, SYS$__CRMPSC, SYS$_MGBLSC, and SYS$__TRNLOG system 
services. A thorough description of requirements and system 
services can be found in References 10 and 17. In addition, 
the following resources are required: 

• Intel development system with edit, compile, and 
liL.; facilities; communication lines and supporting 
software for transmitting data between VAX and 
Intel (development) computers 

• Intel (target) computer with 8087 NDP chip; custom- 
made operating system and other required system 
software; communication lines and supporting 
hardware/software for transmitting data and timing 
information between VAX and Intel (target) computers 

It should be noted that AADS is initially developed on the 
VAX computer. During the second stage, AADS is implemented 
on an Intel computer that is called the target computer. 
However, any modifications to the AADS code required for the 
implementation on the target computer, are made on the Intel 
microprocessor development system (MDS) . The Intel MDS is 
called the development computer and has facilities for edit- 
ing, compiling, and linking Intel executable images. The 
target computer does not have any peripheral devices (no 
disk storage) ; therefore, the Intel executable images are 
stored on the VAX, and downloaded to the target computer 
when required. 

In its final operational phase, AADS will reside in an ex- 
ecutable image form on an Intel microcomputer onboard a 
spacecraft. AADS will have access to the spacecraft clock 
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for timing information, will access data from the onboard 
sensors with the remote interface unit (RIU) , and will pro- 
vide output via the onboard computer (OBC) in the spacecraft 
telemetry. GSS will still interface with AADS by providing 
control information to AADS, and by displaying AADS output. 
Computer resources should be similar to those required for 
the VAX-Intel configuration. The resources will depend on 
the specific mission, and therefore, are not described here. 

4.2.1 FILE STRUCTURE ON THE VAX 

AADS source code, executable images, and other support data 
sets are stored on disk as VAX files. A VAX file is speci- 
fied as DEVICE: [DIRECTORY] filename. type; version. At the 
present time, the disk device DBAO and the default directory 
[AADS] are used for AADS files. The file type describes the 
type of data in the file. The following file types are used 


Pile Type 

Description 


FOR 

FORTRAN source code 


MAR 

Assembly language source 

code 

INC 

INCLUDE files 


OBJ 

Object module output from 
or an assembler 

a compiler 

EXE 

Executable program image 


DIR 

Subdirectory 


COM 

DCL procedure 


LD 

Files for simulator data 


TXT 

Text files (for example, 
tion case descriptions) 

AADS Simula 

SAV 

AADS simulation cases and 
manent data sets 

other per- 

INP 

Input to AADS or AADS simulator 


AADS was developed in four builds. The executive, input/ 
output functions, and interfaces with the AADS simulator 
were tested during builds 1 and 2. The mathematical subsys 
terns for gyro data processing and star data processing were 


implemented in builds 3 and 4, respectively. The files for 
these builds are stored under separate subdirectories as 
follows : 



EX2 Build 2 EXEC source, object modules, 

and compile and link DCL procedures 

102 Build 2 SENS IN, DCAPIN, and OUTPUT 

sources 

GY3 Build 3 GYPROC and PROPAG sources 

ST4 Build 4 STRACK, STARID, and UPDATE 

sources 

STAR Star catalog utility source 

UT Utility routines and object modules 

BTn Executable images, execution DCL pro- 

cedures, simulation cases, and test 
data segments used for the nth build 
(n = 2, 3, or 4) 

CMn INCLUDE files and BLOCK DATA modules 

Build 4 represents the final AADS version on the VAX com- 
puter. Therefore, the subdirectory [AADS.BT4] contains the 
executable images for the completed AADS. 

Some source changes are required for the VAX-Intel version 
of AADS due to the differences between the FORTRAN compilers 
and the operating systems used for the two computers. For 
example, the FORTRAN source, object code, and executable 
images for the VAX-Intel configuration will be stored under 
separate subdirectories. These subdirectories have not yet 
been defined. 

The file structure definition for AADS data sets is given 
above. See Reference 15 for more details on the file 
structure. 
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4.2.2 DATA SET DEFINITIONS 

AADS creates and uses a star catalog during execution. The 
AADS star catalog is a subset of the SKYMAP star catalog 
(Reference 16). utility programs described in Sections 3.10 
and 4.3.4 read the SKYMAP catalog on the IBM S/360-95 com- 
puter and create the AADS star catalog data set used by 
AADS. Table 4-1 shows the format of an intermediate data 
set (MATCAT.DAT) that contains the SKYMAP stars in the 
visual magnitude range 2.0 to 6.5. Table 4-2 shows the 
format of the data set (SORTED. SAV) that contains star 
entries in terms of ascending star right ascension angle. 
This is a direct access data set with a 28-byte logical 
record size, and has 8,666 records. 

SORTED. SAV is accessed by GSS to extract the SKYMAP identi- 
fication number of the stars identified by AADS. SORTED. SAV 
is also used by AADS to create the AADS star catalog. The 
format of the AADS star catalog is described in the file 
DBAO: [AADS. STAR] CAT ADS. FOR. The AADS Star catalog is not a 
data set; it is a data structure internal to AADS, and is 
Stored in the global COMMON area /CATLOG/. 

4.2.3 MEMORY REQUIREMENTS 

Memory requirements can be broken down into global COMMON 
areas, library routines, and code and data. 

on the VAX 11/780 computer, the AADS global COMMON areas re- 
quire 67.4 kilobytes, including the 55.9 kilobytes for the 
Star catalog. VAX/VMS requires that each global COMMON area 
be page aligned (256-byte boundary) . On the Intel 8086/8087 
microprocessor, each global COMMON area must be paragraph 
aligned (16-byte boundary), saving a small amount of memory 
on the Intel. 
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Table 

4-1. Format 

of the 

Data Set MATCAT.DAT 

1 

Byte 



Variable 

Number 

Type 

Description 

BUFVAX (1) 

1-4 

1*4 

SKYMAP number 

RLARR (2) 

5-8 

R*4 

Right ascension 

RLARR (3) 

9-12 

R*4 

Declination 

RLARR (4) 

13-16 

R*4 

X coordinate (GCI frame) 

RLARR (5) 

17-20 

R*4 

y coordinate (GCI frame) 

RLARR (6) 

21-24 

R*4 

Z coordinate (GCI frame) 

RLARR (7) 

25-28 

R*4 

B magnitude 

RLAAR(8) 

29-32 

R*4 

U magnitude 

RLARR (9) 

33-36 

R*4 

V magnitude 

BUFVAX (1) 

. 37-40 

1*4 

Multistar flag 


^The arrays BUFVAX and RLARR occupy the same location in 
memory (they are equivalent) . 
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Table 4-2 


Format of the Sorted Data Set SORTED. SAV 


Variable^ 

Byte Number 

Type 

Description 

lOUTBF(l) 

1-4 

I* 4 

SKYMAP number 

ROUTBF (2) 

5-8 

R*4 

Right ascension 

ROUTBF (3) 

9-12 

R*4 

Declination 

ROUTBF (4) 

13-16 

R*4 

B magnitude 

ROUTBF (5) 

17-20 

R*4 

U magnitude 

ROUTBF (6) 

21-24 

R*4 

V magnitude 

IOUTBF{7) 

25-28 

1*4 

Multistar flag 


^The two arrays lOUTBF AND ROUTBF describe the same memory 
locations (they are equivalent) . 


On the VAX, library routines include FORTRAN library, record 
management service (RMS) routines, and system vectors, tak- 
ing an average 110 kilobytes per process. On the Intel, a 
stack takes one-to-two kilobytes (with the system vectors 
adding slightly more) . A two-to-three kilobyte math library 
will be shared between all processes. 

The memory used by each process for code and data is sum- 
marized in Table 4-3. The figures for the VAX routines in- 
clude code used to generate diagnostic test output. The 
figures for the Intel routines were determined by multiply- 
ing the figures for the VAX routines by a conservative ex- 
pansion factor of 2.0 and adding two kilobytes for the stack 

The current estimates for the Intel operating system, math 
library, and the AADS COMMON areas are i.wluded to help give 
an overall picture of the total memory requirements. The 
fourth column in Table 4-3 gives the original memory re- 
quirements estimated during the preliminary analysis for 
AADS. The figure for the executive process was obtained 
from Reference 5. All other figues were obtained from 
Reference 11. These figures are included for comparison 
purposes. The fifth column gives the memory space require- 
ments, for example, format statements and literals. Thus, 
approximately seven kilobytes of total memory space are re- 
quired for diagnostic test output in the VAX version. This 
translates to approximately 15 kilobytes for the Intel ver- 
sion. The final operational version of AADS will not 
contain the diagnostic test code, and will save the 15 kilo- 
bytes of memory space. 

4.2.4 TIMING STUDY 

AADS timing study has not yet been conducted. This informa- 
tion should be added to the document when the timing study 
has been completed. 
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Table 4-3. Memory Requirement Summary 


TASK 

CURRENT VAX 
MEMORY 
(KILOBYTES) 

PREDICTED 
INTEL MEMORY 
(KILOBYTES) 

ORIGINAL MEMORY 
estimates (KILOBYTES) 

EXEC LESS 

OCCULTATION 

PREDICTION 

10.6 

23.2 

22.0 

OCCULTATION 

PREDICTION 

4:1 

8.2 


SENSIN 

3.2 

a4l 

2.0 

DCAPIN 

8.9 

19.8 ; 


OUTPUT 

9.5 

21.0 

11.0 

GYPROC 

6.2 

14,4 

4.0 

PROPAG 

11.6 

25.2 

4.0 

STRACK 

16.5 

35.0 V 

8.0 

STAR ID 

29.8 

59,6 f 


UPDATE 

6.9 

15.8 

4.0 

OPERATING 

SYSTEM 


’1 

16.0 

MATH LIBRARY 




AADS GLOBAL 

67.4 

67.4 

STAR CATALOG COMMON 

COMMON AREAS 
INCLUDING 
STAR CATALOG 



AREA ONLY 142K 

TOTALS 

174.7 

313.0 

213.0 

















4.3 EXECUTION AND SYSTEM GENERATION 


The following sections describe in detail the DCL procedures 
used in system generation and execution. See Reference 15 
for additional details. 

4.3.1 COMMAND FILES 

Command files exist for AADS generation and execution. 

These files contain DCL statements to compile the source, 
link the object modules and run the AADS system or utility 
programs. Command files reduce the amount of typing for 
system generation and execution, and eliminate setup 
errors. There are nine AADS processes under four subdirec- 
tories, each directory containing a compile and a link com- 
mand file. In addition, there is a run command file for 
AADS and the AADS simulators. The utility program TMPCOMCRE 
has a similar command file. A HELP data set is available 
for most of the command files. The following sections will 
discuss in detail the use of these command files for system 
generation and execution. 

4.3.2 SYSTEM EXECUTION 

Both AADS and the AADS simulator reside on the VAX computer 
during initial testing (configuration 1) , because better 
software development facilities are available on the VAX 
computer. AADS is eventually implemented on the Intel 8086 
c'omputer and communicates with the AADS simulator using spe- 
cial communication lines between the VAX and the Intel com- 
puters. The VAX-Intel configuration is referred to as 
configuration 2. 

To simulate the communication between AADS and the AADS sim- 
ulator for configuration 1, mailboxes are used (uplink and 
downlink messages) . The AADS simulator transfers the raw 
sensor data to AADS through a mailbox. A separate process 
stores the data in a global COMMON area, which is accessed 

4-15 



by AADS on a regular basis depending on the sensor data col- 
lection schedule. The mailbox and the associated process 
simulate the direct memory access (DMA) method that will be 
used for configuration 2 to store sensor data for AADS. The 
following sections describe these two cases in more detail. 

4. 3.2.1 VAX System Configuration 

Figure 4-1 shows the command file used for a simulation run 
of AADS and the AADS simulator during build 2 testing. The 
command files used for build 3 and build 4 are quite similar 
to the build 2 command file and the differences, if any, 
will be transparent to the user. The final version of the 
command procedure should be available in the VAX file 
DABO : [AADS.BT4JBLD4.COM. The command procedure prompts the 
user for the location of test data, start and end times for 
test data, and the wall clock time at which the simulation 
should start. The AADS and AADS simulator processes are 
then initiated and the control is transferred to GSS. GSS 
puts up several menu and parameter displays that are used to 
specify AADS execution during the current simulation run. 
Finally, GSS stops the simulation run on request and allows 
selective printing of the AADS output reports and any op- 
tional diagnostic test output. 

4 . 3 . 2 . 2 VAX-Intel Configuration 

The executable form of AADS software is downloaded to the 
Initel 8086 microprocessor from disk files on the VAX-11/780 
computer. Creation of this executable form is described in 
Section 4.3.3. Mor • information on the downloading proce- 
dure can be found in Section 1.3.1 of Reference 10. Two 
data communication channels are used between the VAX-11/780 
computer and the Intel 8086 microprocessor. The first is 
used for communication between AADS and the OSS. The second 
is used by the SDS to send simulated sensor data, which the 
Intel operating system receives and stores in a global 
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ORIGINAL PAGE 
OF POOR QUALITY 


luu $ i 

s : iniS ib Tht c.U(>ii<iArUj Klitc: Kurt AAOS/AAt)Slh bOibU 2 extCU'fiUrl. 

3uo $ i XU il1VU^r., 'iKl'b: i<tbLU‘<^, 

40U S i 

SruO S SiilX UbK lAAUS.bT2J 

6u0 $ ScX U>v 

7U0 S Se.X Cui«l'«Ub-K 

UUO S ■-•KXXt: SiSSUUTKuT "AADS/AADSim SiMULAXIUN SXAHXXUS - BUILD 2" 

90U S : biMABLS BHKUK XHANSfKKB AND CONTRUL.X 

lUuO S : INXk:HKUK'l.'S 

XlUU Si 

12U0 S l.JyUXKt ALUC.V b«XLH OUXBUX UbVlCh; KOK ACXIVl'X'X LUti 
XiOU $ i 

14UU S : ASK USIilK XU bNTbK UBVXCE NAME 

X5UO S 1 

iSOU $ IK ALObV .tUS, XriEN ALUEV :s "UBAO" 

X7UO $ i 

IBUU S : XK I4ULL SXKIUU ENXEREU XHEN SEX XO 

X9UU $ i UEKAULX 

20UU Si 

21U0 $ INLEN = •f'SLENLXH(ALUEV) i KINO LENti'X'rt UK XNFUX SXRING 

22UU $ UNUbK s Xt'K$LUCAXEC."rALUEV} i LUUK KOK UNDERSCORE 

2iUU S IF under .£u. XriLENti I'HEii UnDER s U 
24U0 Si 

ibUO $ i XK NONE KOUND SeX UNDER XO U 

2bUU S i 

27uu $ CULUn s 'KSLUCAXEC*:". ALUtV) i LOOK FOR COLUN 

2BU0 S LEVLEU = CULUn • UnDEP i NUrlBER OK CHARACTERS AFTER . AND 

2900 $ i BEFORE I 

iOOU S i 

iXUO S DEVNAR :s • KSEAXRACXIUnUEK»DEVLEn,ALUEV} 

32o0 $ i 

iJUO $ i EXTRACT RRURER DEVICE NAME 

3400 Si 

3500 $ IF OEVNAR .EUS. ”UHAU'' .UR. OEVNAn ,EUS, "DBBX” XHEN GOTO SKIP 

3«J00 Si 

3700 $ t DU NUT ALLOCATE IF DISK IS SPECIFIED 

3B00 Si 

3900 S ALLUCA'IE 'ALUEV i ALLOCATE DEVICE 

4000 s assign 'ALDEv* ACXLUG 

4100 S SEX' NUUW 

4200 S SKIP: 

4300 $ sexr: 

4400 si 

45u0 $ i SENSOR DATA SUbSVSTfcM C SDS) — — 

4b00 S. i 

4700 S WKIXE SySSUUXPti'X' "SENSOR DATA SUbSXSXEn STARTING” 

4900 S SEX NOUn 

4900 S SXIrE :a 'KSXXMEU' 

bOOO S BLAkK i= 'FSL.UCAXEX" ".S'XIMEJ* 

bioo S SX'lHElbLANK.l J ;s: 

b200 8 UI'J CUNXRUL^V XHEN GLIXU rttiSXAKX 

5300 S run Mb2GS/6»RUCSNB2GS/PRIUHXXl( = X2 

5400 $ kesxakx; 

9500 S INUUXRE HUHKNN "EilXER NEAUEK FXLE NAME SXRXNG” 

5500 S X 'iUUXRE KNh "B.MXEK DATA KXLE NAME STRING” 

5700 S XivuUXKE RtPKXLE "ENTER REPUK'X FXLE NAME SXRXNG UK KNUMn}" 

9900 S XK ReRKXLE.EUS."" XHEn GUXU HHKANGE 
9900 S s?LOeKILE 'REKKILE' 'KNM' 

5000 s ihikanGe: 

blOU S UKEn/nRIXe St>S.oSERlN SDSXN.ijAX 


Figure 4-" 1, DCL Procedure for AADS Simulation Run (1 of 3) 
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ORIGINAL PAGE jS 
OF POOR QUAUTT 


e'<2u0 

b3UU 

t>4yu 

bbCiO 

bbUb 

bVyg 

bWou 

o9y0 

/ooy 

/lUU 

7200 

7300 

7400 

?bOO 

7600 

7700 

7800 

7900 

HUOO 

HlOO 

6200 

H300 

8400 

8^00 

h6oo 

8700 

8800 

8900 

9000 

9100 

9200 

9300 

9400 

9600 

9600 

9700 

9800 

99o0 

10000 

10100 

10200 

10300 

10400 

lOSOO 

loaoo 

10700 

10800 

10900 

11000 

lllUO 

11200 

11300 

114O0 

llboo 

liboo 

11700 

11800 

11900 

12000 

12100 

12200 


S .vKii'fc, Sli.'>«Ui»fcKir, " " 

$ C.ijJ8t boS_o&e.Kl>'; 

$ iNfJOlHK STUAl'A "fcii'i'KK STAKT Xlrtb Ulf' OAXA ISIM J 1 IMMUO, HHMMS5MMM) " 

S I 'lvjulKt tTOAl'A "Kr.'ifcH XlrtE UK DATA (SiMm«40D,HHMMSSMMInJ " 

s ^iwiik: aifasuu'ivux '•cukhki'*!' waou xint is i" 

S ShO»* 'I'lMt 

S UvuOlKt, STviAUb ''KinIKK SXAKT XiMK OK OAl'A (HAlibt lXMMt)U«HHNHSSNMNJ " 

$ AAUSXif^bS AAOSX'ii'ib'SiUA'l' 

S rtWIlfe. AAOSXIHLS STOATA 
S --KITE AADS’l'IriiiS bXUATA 
$ »<Kl'l't AAOSTliibS STAAbli 
S COUSb AAOSTl.'ibS 

$ ASSlOfI /UkOUK AAOS'l'XMKS.UAX KUK032 
$ ASSlCiW ^'CiKuUK 'HURKNM' HOKKILb 
$ ASSl(j.'< /UKOOK SUSKbHOKX.UAX SUSKKHUKX 
$ ASSlO'Ai /UKUUK SOSKKPUKX.UAT KOM037 
$ Ui\ CUx^XKUU.l THKn GOXO OUlX 

$ HON SUayS/PKOCe.SS.NAHesm)SKS/lNPUXsSOSlN,UAX/UUXPUXsSUSQUT.t)AT 
8 <tAlX ootooilb 

S 1 

S t UN80AH0 SUHKUKX SuBSYSXbH (USSJ 
Si 

$ khIXK SySSQOXKUX ''QN8UAK0 SOKPOKX SUbSlSXKH SXARTING" 

$ HON USSiM/PHUCtSS.NAH£«USSli4/PH10HrXlBlS/0gfil»UXs0SS ' 

Si 

S i AUXUNUHOOS AXXIXUOK ObXbKMlN AXIUN SISXEM (AAUS) 

Si 

8 MHlXfc: S1S8U0XHUX “AAOS SXAKXING" 

8 KON bXbC.bXbri/HKUCKSS.riAnbaAAUS/PRlURlXYBlS/UUXPOI*' ALOeV 
S 1 

8 1 GHUUNO 5UPPUHX SObSXSXbn IGSS) 

$ i 

8 *81X1:: SlSsUUXKUX "GKOUNU SUPPUKX S08SYSXKM SXAKXlNG" 

5 '*81X1:: SySSOOXPUX "XHIS SObSYSXEA IS HUN INIERACl'l VEliX KKON THIS TGMNlNAli 

6 nRlXE SySSOUXPOX "COHHEHX 8AUL XING ISI” 

S ShO» XlMt 

S nHlXG SySSUUXPUX ''SXAKX XIHG UK SIM. ISl" 

S i^iHlXt SySSUUXPOX SXNAJal, 

S ASSIGN XX SySSlNPUX 

$ shcn xhans syssiNPux 
$ *AXX 00 too 11b 

$ HON GSS 

$ t 

8 ! XbHMiNAXG ALL. HKUCESSGS 
Si 

8 ouix: 

S UN CUNXKUL.y XHGn GUXU fin 
8 SXUP GIKOSIM 
8 STOP SXARblM 
8 SLOP MblGS 
8 STOP SOSXS 
8 SXUP USSlM 
8 SXOP AAU'j 
8 SXUP GS'JPtH 
8 SXUP {'SSIM 
S AGAIKI NAlX UOlOOllb 
8 SHUU SISXEM 

8 INOUIHG CLGAHbU ALL AAUS PKUCGSShS UOX OK SySXGM? CX/N) 

8 IK .nOX. CLGAHGO XHGN GOXU AGAIN 
8 oGALLOCAXG 'ALOGV 

S iNUOlHb WANT uUXPOX XU THE PHINXEK? CY/tt) 


Figure 


4-1. DCL Procedure for AADS Simulation Run (2 of 3) 


ORIGINAL PAGE m 
OE POOR QUALITY 


IZ3U0 

1;<4UU 

l^bUO 

126UU 

127UU 

128U0 

129UO 

liOUU 

lilUO 

132UU 

133UO 

134UU 

iiSoO 

13600 

13700 

13800 

13900 

14000 

141O0 

14200 

14300 

14400 

14500 

14600 

14700 

14800 

14900 

16000 

16100 

16200 

16300 

16400 


S IK .rtU'l'. "ANX (ioro KIN 

S i 

$ 1 UUl'HUI 

s : 

8 uoiHUi': 

$ OIK /Sli^Cbs'S’llME' /Si;^!:: 

$ •nKll'b 616 SU 0 TKUT "IK EXCESSIVE UO'i'PUl, GO XU 2 NU XEKNINAU AND RENAME 
$ '.'KITE SySSUUXKOX "SELECTEO UAX KILES XU ANUXHbK TXPE," 

$ iKUOlHE UK IS AMUONX MF UOTPUX UK? U/NJ 
S IF .iVOT. UK XHEN GUXU OUXFUT 
S KEivAHE FUKUU 8 .UAX;* FUR 0 u 8 . 81 N)« 

$ KEi^Artb rUKOOS-yAT?* F(JHaQ9saiN}* 

$ KbiVAi'^E FUKU 13 ,UAX;« FUK 013 , 81 n;« 

$ KEivAMb FUKU 14 . 0 AX;« FUKU 14 , 81 N;* 

S RENAME FOK 016 .UAX;* FOKUlS.UliVfO 
S rename FUR 033 , 0 AX ;8 F 0 KU 33 , 81 n|« 

$ rename FUR 034 , 0 AX ;4 FURU 34 . 81 NI* 

S FHXIVT /FLAG.PAGE BL 02 .CUM 
$ OIK /S 1 RCEb'SX 1 ME'/S 12 £/PK 1 NXEH 
$ PRINT /FUAG.PAUE 8 .UAT;* 

« OOMP FUK 008 , 81 n; 1 /PRZNTEK/U 0 UCKSs(START: 1 »END| 5 ] 

8 OUMP FUR 0 U 8 , 8 lM: 2 /PRlNTEK/bLUCKSB(STARm,EN 0 l 5 ) 

$ OUMP FUK 0 U 9 . 8 lN;l/PRINXEH/HLUCKSs(SXARXtl>ENUl 5 ) 

$ OUMP FDKU 09 ,BlN; 2 /PKINTEK/tiLUCKSS(SXARXll*ENUIS| 

8 OUMP FUK 013 ,bXN/PKlNXEK/ 8 LUCKSS(SXAKX:l,ENU{ 6 ) 

8 OUMP FOKU 14 ,bXN/PKlMXEK/bOUCKSsCSXARXtl»ENU> 6 ] 

8 DUMP FUK 016 ,blN/PKlNTEK/b 0 UCKS«(STARXtl »ENUt 5 ) 

S OUMP FUK 033 «blN/PRlNXEK/b 0 UGKS«( 5 XAK£ll,ENU| 5 ) 

8 DUMP FOK 034 ,BiN;l/PRXNTEK/bliUCKSB(SXARXtl»ENUl 5 ) 

8 OUMP FOK 034 .SlH; 2 /PRZNIEK/bOUCKSa(STARTtl,ENOiS) 

8 fin: 

8 EXIT 


Figure 4-1. DCL Procedure for AADS Simulation Run (3 of 3) 


COMMON area using DMA. More information on the communica- 
tion between the VAX-11/780 computer and the Intel 8086 
microprocessor can be found in Reference 10. The command 
file used to transfer AADS software to the Intel 8086 micro- 
processor and run AADS and the AADS simulator has not been 
defined at the present time. 

4.3.3 SYSTEM GENERATION 

DCL procedures to compile source code and to create execut- 
able images for all AADS processes are available in command 
files. Compilation and image creation is described in de- 
tail for the input/output and executive processes. Compila- 
tion and image creation procedures for gyro and star data 
processes are similar in most respects. 

Figures 4-2 through 4-5 show the • procedure for compiling the 
source for the input/output (SENSIN, DCAPIN, and OUTPUT) 
processes. The first command file, [AADS.I02JCOMP.COM ref- 
erences files SENSIN.COM, DCAPIN.COM, or OUTPUT.COM in the 
[AADS. 102] subdirectory, depending on the process name se- 
lected. Compilation of diagnostic test lines (D_LINES) , and 
the amount of compiler output depends on the options se- 
lected during the execution of the procedure. Figures 4-6 
through 4-9 show the command files under the subdirectory 
[AADS. 102] that are used for creating executable images for 
SENSIN, DCAPIN, and OUTPUT processes. Again, the command 
file LINK.COM references SENSIN1.COM, DCAPIN1.COM, or 
OUTPUTl.COM, depending on the process selected. Generation 
of the LINK map is optional. 

All the link-editor input files include [AADS, CM 2] COMMON. OPT 
as an options file. Figure 4-10 shows this file. This file 
includes the object modules for the global COMMON areas us- 
ing the cluster option, creating the virtual address space 
and forcing the page alignment necessary for the creation of 
temporary global COMMON areas on the VAX-11/780 computet. 
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ORfQIMAL PmW [SI 
OF. POOR QUALIW; 


100 $! 

200 $! COMMAND FILE FOR COMPILING ROUTINES FOR AADS 10 PROCESSES 

300 $! [AADS. 102 jCOMP.COM 

400 $ I 

500 $SET DEFAULT [AADS. 102] 

600 $ASSIGN [AADS. CM2] LOGGL 
700 $ASSIGN [AADS. CM2] LOGIO 
800 $ASSIGN [AADS. CM2] LOGRIU 

900 $WRITE SYS$OUTPUT "PROCESS NAMES: SENS IN.. DCAPIN, OUTPUT" 
1000 $ INQUIRE PROCESS "ENTER PROCESS NAME" 

1100 $INQUIRE LISTOPT "DO YOU WANT A LISTING? CY/N)" 

1200 $INQUIRE DOPT "DO YOU WANT DEBUG LINES? (Y/N)" 

1300 $IF .NOT. LISTOPT THEN GOTO B1 
1400 $IF .NOT. DOPT THEN GOTO A2 
1500 $Al: 

1600 $FOR/D_LINES/LIST=LPO: @ 'PROCESS' 

1700 $GOTO END 
1800 $A2: 

1900 $FOR/LIST=LPO: g'PROCESS' 

2000 $GOTO END 
2100 $Bl: 

2200 $IF .NOT. DOPT THEN GOTO B2 
2300 $FOR/D_LINES PROCESS' 

2400 $GOTO END 
2500 $B2 : 

2600 $FOR @' PROCESS' 

2700 GOTO END 
2800 $END: EXIT 


Figure 4-2. Compilation of Input/Output Functions 
File [aADS. 102] COMP. COM 


100 SENSIN,SIGYRO,SIFHST,TIMOBT,B8ADD 
Figure 4-3. Compile Input File [AADS. 102] SENS IN. COM 

00 DCAPIN,DCAP,QLONG,STOEPH,DCAPIP^ INPUT, INEPH, INFULL 

00 HEADER, STCDAT 

Figure 4-4. Compile Input File lAADS. 102] DCAPIN.COM 

1 OUTPUT,OBOUT,HIPRI, REPORT, UPDRPT,OUTACT,RAWDAT, RPY,- 
I TIMOBT,B8ADD 

Figure 4-5. Compile Input File lAADS . 102] OUTPUT. COM 



ORiGiNAL PASS \M 
OF POOR QUALITY 


Ido $! 

200 $! COMMAND FILE TO LINK-EDIT AADS 10 PROCESSES, - 

300 [AADS. 102] LINK.COM 

400 $! OPENGL IS A MACRO ROUTINE 

500 $ ! 

600 $SET DEFAULT [AADS. 102] 

700 $WRITE SYS$OUTPUT "PROCESS NAMES: SENSIN, DCAPIN,- 
800 OUTPUT" 

900 $INQUIRE PROCESS "ENTER PROCESS NAME" 

1000 $ INQUIRE MAPOPT "DO YOU WANT A LINK MAP? (Y/N) " 

1100 $IF .NOT. MAPOPT THEN GOTO B1 
1200 $A1: 

1300 $LINK/EXE= [AADS.BT2] ’PROCESS' . EXE/MAP=LP0 : @ 'PROCESS '1 
1400 $GOTO END 
1500 $B1: 

1600 $LINK/EXE=[AADS.BT2] 'PROCESS' .EXE @'PROCESS'l 
1700 $END: EXIT 


Figure 4-6. Link Conunand File [AADS.I02JLINK.COM 


100 SENSIN,SIGYRO,SIFHST,TIMOBT,B8ADD,OPENGL, - 
200 [AADS. CM2] COMMON/OPT, COMMON/OPT 


Figure 4-7. Link-Editor Input File IAADS.I02jSENSlNl.COM 


100 DCAPIN,DCAP,QLONG, STOEPH^DCAPIP^ INPUT^ INEPH, INFULL, - 
200 HEADER, STCDAT, 

300 [AADS .CM2] COMMON/OPT 


Figure 4-8. Link-Editor Input File [AADS. 102 jDCAPINl.COM 


100 OUTPUT, OBOUT, HI PR I, REPORT, UPDRPT,OUTACT, RAWDAT,- 

200 TRPY,B8ADD, 

300 [AADS. EX2] TIMOBT, [AADS. CM2JCOMMON/OPT 


Figure 4-9. Link-Editor Input File [AADS.I02jOUTPUTl.COM 


4-24 


ORIGfMAL PmS. 

OF POOR QUAUr/ 


100 
2 00 
300 
400 
500 
600 
700 
800 
900 
1000 


CLUSTER 

CLUSTER 

CLUSTER 

CLUSTER 

CLUSTER 

CLUSTER 

CLUSTER 

CLUSTER 

CLUSTER 

CLUSTER 


^GLOBAL, , 
ACTVLG, , 
CATLOG, , 
SENSOR, , 
FLIGHT, , 
STATE,,, 
STATl,, , 
STAT2, ,, 
STAT3,,, 
STAT4,,, 


, [AADS 
, [AADS 
, [AADS 
, [AADS 
, [AADS 
[AADS. 
[AADS. 
[AADS . 
[AADS. 
[AADS. 


.CM2JGLOBAL 
.CM2] ACTVLG 
.CM2] CATLOG 
.CM2] SENSOR 
.CM2] FLIGHT 
CM2] STATE 
CM2]STAT1 
CM2]STAT2 
CM2]STAT3 
CM2]STAT4 


Figure 4-10. Link-Editor Input Options File 
[AADS . CM2 ] COMMON. OPT 
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The link-editor input file for the SENSIN process includes 
[AADS. 102] COMMON. OPT as a second options file. This file is 
shown in Figure 4-11. This file includes the object module 
for the /RIU/ global COMMON using the cluster option. 

Figures 4-12 through 4-16 show the command procedures used 
to compile the source code and to create the executable 
image for the EXEC process. All procedures are under the 
default directory [AADS.EX2]. The procedure in file 
COMP.COM (Figure 4-12) is used to compile the source code 
for the EXEC process and uses the input file EXEC.COM (Fig- 
ure 4-13) . Figure 4-14 shows the link command procedure in 
the file LINK.COM, which refers to the link input file 
EXEC1.COM (Figure 4-15) . The link procedure uses two input 
options file. The first file is [AADS. CM2] COMMON. OPT shown 
earlier in Figure 4-10. The second options file 
[AADS. EX 2] COMMON. OPT (Figure 4-16) includes the object mod- 
ule for the /ADSGBL/ global COMMON area using the cluster 
option. 

System creation of AADS, where AADS is to be executed on the 
Intel 8086 target microprocessor, is done by transferring 
the source code to the Intel MDS (development computer) . 
There the code is compiled and link edited as modules in the 
Intel absolute object file format. The code, as modules, is 
then transferred back to the VAX-11/780 computer, from which 
it can be downloaded to the Intel 8086 microprocessor. The 
code transmission is done through 1200-band dialup lines. 
Figure 4-17 shows the system configuration used for system 
creation. 

4.3.4 EXECUTION AND CREATION OF UTILITY PROGRAM 

Figure 4-18 shows the command file used to link edit and 
execute the TMPCOMCRE utility program. This program is used 
to Initialize the global COMMON areas used by AADS with 
block data values. TMPCOMCRE does this by creating the data 
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100 CLUSTER=RIU, , ^ [ AADS . CM2 ] R I U 

Figure 4-11, SENS IN Link-Editor Input Options File 
[ AADS . 102 JCOMMON . OPT 


00100 
00200 
00300 
00400 
00500 
00600 
00700 
00800 
00900 
01000 
01100 
01200 
01300 
01400 
01500 
01600 
01700 
01800 
0190 0 
02000 
02100 
02200 
02300 
02400 
02500 
02600 
02700 


$! 

$! COMMAND FILE FOR COMPILING THE AADS EXECUTIVE, 
[AADS. EX2] COMP. COM 
$! 

$SET DEFAULT [AADS.EX2] 

$ASSIGN ’[AADS. CM2] LOGGL 
$ASSIGN [AADS. CM2] LOGEX 
$ASSIGN [AADS.BT2] LOGBLD 

$WRITE SYS$OUTPUT "ROUTINES FOR PROCESS EXEC- 
WILL BE COMPILED" 

$INQUIRE LISTOPT "DO YOU WANT A LISTING? (Y/N)" 
$INQUIRE DOPT "DO YOU WANT DEBUG LINES? CY/N)" 

$IF .NOT. LISTOPT THEN GOTO ai 
$IF .NOT. DOPT Then goto A2 
$Al: 

$FOR/ D- LINES/ LI ST=LP0: @EXEC, OCCULT 

$GOTO END 

$A2: 

$FOR/LIST-LP0: 0EXEC, OCCULT 

$GOTO END 

$B1: 

5lF .NOT. DOPT THEN GOTO B2 
$FOR/D_LINES SEXEC, OCCULT 
$GOTO END 
$B2: 

$FOR @EXEC, OCCULT 
$END: EXIT 


Figure 4-12. Compile Command File [ AADS. EX2] COMP. COM 
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00100 

00200 

00300 

00400 

00500 

00600 

00700 

00800 

00900 

01000 

01100 : 

01200 

01300 

01400 

01500 
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00100 ACTLOG,CMDPRO, ENQ'JE, EXEC, INITL, SCHED^HMS, TIMEUP,TSKDNE, - 
00200 UPSTAT, TASKS, BLDLOG, MAIN, FLAGS, CANCEL, TIMOBT,B8ADD 


Figure 4-13. Compile Input Pile {AADS.EX2JEXEC.COM 


$! 

$! COMMAND FILE TO LINK-EDIT THE AADS EXECUT I VE, - [ AADS . EX2 J L I NK . COM 
[AADS.EX2 JLINK.COM 

$1 OPENGL IS, A MACRO ROUTINE WHICH IS ALREADY COMPILED 

$! 

$SET DEFAULT [AADS.EX2J 

$WRITE SYS$OUTPUT "PROCESS EXEC WILL BE LINKED" 

$INQUIRE MAPOPT "DO YOU WANT A LINK MAP? CY/N>" 

$IF .NOT. MAPOPT THEN GOTO B1 
$Al; 

$LINK/EXE= [AADS. BT2]EXEC.EXE/MAP = LP0: iiJEXECl 

$GOTO END 

$Bl: 

$LINK/EXE= [AADS. BT2JEXEC.EXE @EXEC1 
$END: EXIT 


Figure 4-14. Link Command File [AADS.EX2JLINK.COM 
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00100 ACTLOG^CMDPRO, ENQUE, EXEC, INITL, SCHED, HMS , T I MEUP , TSKDNE 

00200 UPSTAT, TASKS, BLDLOG /MAI N, FLAGS , CANCEL, T I MOST, B8AOD, - 

00300 OPENGL, OCCULT, - 

00400 [AADS,UT]MATMPY,UNVEC,SMPOS, [AADS.ST] INTERP,- 
00500 [AADS. CM2] COMMON/OPT, [AADS .EX2] COMMON/OPT 


Figure 4-15. Link Input File [AADS. EX2] EXEC1.COM 


00100 CLUSTER=ADSGBL,,, [AADS.CM21ADSGBL 
Figure 4-16. Link Input Options File [AADS. EX2] COMMON. OPT 
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Figure 4-17. VAX- Intel System Configuration Used for 
System Generation of Intel Executable 
Image of AADS 







100 $ASSIGN [AADS.CM2] LOGGL 
200 $FOR TMPCOMCRE 

300 $L1NK TMPCOMCRE, [AADS.EX2JOPENGL, [AADS.CM2JCOMMON/OPT 
400 $RUN TMPCOMCRE 


Figure 4-18. DCL Procedure To Link and To Execute 
TMPCOMCRE Utility Program on VAX 



set [AADS.GL1C0MM0N.DAT. Block data values that were link 
edited into TMPCOMCRE are written to this data set. This 
data set is then used in the creation of the temporary 
global COMMON areas. 

No command files exist for the star catalog generation util- 
ities. Creation of these utilities is accomplished with a 
simple compilation and link edit. The remainder of this 
section contains execution instructions for these utilities. 

The IBMVAX utility program converts a tape containing the 
star catalog from a IBM S/360-95 computer to a data set on 
the VAX computer. 

Before running this utility program, the tape is mounted and 
the following DCL commands are executed; 

MOUNT/FOREIGN/DENSITY=1600 MTAO 
ASSIGN MTAO: FOROOl 

This utility program will create the direct access data set, 
MATCAT.DAT, on the logical unit FOR039. Additional output, 
formatted for viewing purposes, will be created on the logi- 
cal unit FOR006. 

The SORT utility program sorts the direct access star cata- 
log data set created by IBMVAX. The star catalog entries 
are sorted by ascending right ascension angle values. Be- 
fore running this utility program, the input data set is 
assigned to the logical unit FOR038, as in the following 
example : 

ASSIGN MATCAT.DAT FOR038 

Output will go to the logical unit FOR039. Additional out- 
put, formatted for viewing purposes, will go to logical unit 
FQR006. The output, FOR039.DAT, should be renamed to 
SORTED. SAV, if it is satisfactory. This data set is ac- 
cessed later by the STARID process of AADS on unit FOR039 to 
initialize the Star catalog COMMON area. This data set is 
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also used by the GSS process to obtain the SKYMAP star iden- 
tification numbers for the stars identified by AADS. 

4.4 AADS CONTROL PARAMETERS 

AADS control parameters are divided into four broad types, 
as follows: 

• Scheduling frequencies and output parameters 

• Initial state, gyro data processing, and state 
propagation parameters 

• Star data processing, star identification, and 
state update parameters 

• Occultation prediction parameters 

The parameter descriptions are taken from BLOCK DATA rou- 
tines stored under the subdirectory [AADS.CM2J. The files 
STATl.FOR, STAT2.FOR, STAT3.FOR, and STAT4.FOR should be 
consulted for the current descriptions of these variables. 

In addition to the control parameters, AADS execution can be 
controlled (although at a higher level) by using such AADS 
commands as START, STOP, HALT, RESUME, and STOP. These com- 
mands are described in Section 2. 


4.4.1 SCHEDULES AND 

PRIORITIES 

VARIABLE 

TYpR 

default description 

MPDELT 

R*4 

29,75 

time difference (SECONDS) BETWEEN 

THE SCHEDULED TIME OF THE LAST UPDATE 
AND THE start OF THE STAR DATA PROCB* 
SSING FOR THE NEXT STAR UPDATE, 

GyOEtiTf25 

Cl) 

C2) 

R44 

0,512 

0,256 

GYRO DATA PROCESSING TASK PERI0D(SEC0ND 
nominal processing PERIOD 
PERIOD DURING A MANEUVER, 

STDELT 

R4>4 

0,512 

SCHEDULING PERIOD FOR THE STAR DATA 
DATA PROCESSING TASK (SECONDS), 

npLIM 

R*4 

420,0 

MAXIMUM TIME PERIOD WITHOUT A STATE 
UPDATE, AADS GENERATES AN ERROR MESSAGE 
IF THERE IS NO UPDATE FOR UPLIN SECONDS 
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SNOEliTf2) 

(n 

C25 


IGYRPC2) 


MPR0UTf21 

( 2 ) 

NUPOUT 


NATOUT 


NRWOUT 


TSKPRI(IO) 


LEVORG 


R«4 

0 

.064 

SCHEDUtiINQ period FOR THE SENSOR DATA 
COLLECTION TASK (SECONDS) 

GYRO DATA SAMPLING PERIOD. 


0 

.100 

STAR DATA SAMPLING PERIOD. 

DATA PROM BOTH THE TRACKERS IS COLLECTED 




AT THE SAME TIME 

1*4 

1 


NUMBER OP TIMES GYRO DATA PROCESSING 
TASK INVOKED BEFORE SCHEDULING GYRO 
PROPAGATION TASK. 

DURING NOMINAL PROCESSING 


1 


during maneuver 

1*4 


1 

number of state propagations before 

REQUESTING DATA ANNOTATION REPORT. 



1 

DURING normal PROCESSING 



1 

DURING MANUEVER 

1*4 


1 

NUMBER OF UPDATES BEFORE REQUESTING 
UPDATE REPORT 

1*4 


120 

NUMBER OF PROPAGATIONS BEFORE REQUESTING 
ACTIVITY LOG OUTPUT 

1*4 


120 

NUMBER OF PROPAGATIONS BEFORE REQUESTING 
RAM SENSOR DATA OUTPUT 

1*4 


15 

TASK PRIORITY INDICATOR 
PRIORITIES RANGE FROM 1 TO 31 HHERE 1 IS 
THE LOWEST AND 31 THE HIGHEST 
(1) • OCAP 



IS 

(2) • INPUT 



14 

(3) • SEN8IN 



10 

(4) • 6YPR0C 



10 

(5) • PRQPAG 



6 

(6) • STRACK 



6 

(7) - STARID 



6 

(8) - UPDATE 



8 

(9) - OUTPUT 



12 

(10)- EXEC 

1*4 

10*0 

LEVEL OF DEBUG OUTPUT FOR EACH TASK 




INDEXES ARE THE SAME AS TSKPRI ABOVE 
0 MEANS NO DEBUG OUTPUT 
10 MEANS MAXIMUM DEBUG OUTPUT 
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4.4.2 INITIAL STATE AND TIME, AND GYRO PROCESSING PARAMETERS 


VARIABT.E 

TYPE 

default 

description 

AQTIME 

R«R 

a i 1001, 03 

TIME OF THE INITIAL STATE (YYMMDO.HHMMSS 


THE EXECUTIVE TASK WILL START SCHEDULING 
OTHER AADS TASKS AT THIS TIME. 


AQUATPfAl 

R«4 

• 

INITIAL STATE IN QUATERNION FORM AT 
TIME QTIME, 

rn 


.062885 

quaternion 1 

t2) 


-.168893 

QUATERNION 2 

(31 


-.055597 

QUATERNION 3 

(4) 


.982054 

QUATERNION 4 

ASTCDV(6,6) 

R«4 


INITIAL covariance MATRIX AT AQTIME 
(UNCERTAINTY)**2 IN UNITS OF RADIAN«*2 

(1,1) 


4.E«4 

uncertainty**! FOR QUATERNION 1 

(2,2) 


4.Ef»4 

UNCERTAINTY**! FOR QUATERNION 2 

(3,3) 


4.E*4 

uncertainty**! for quaternion S 

(4,4) 


4.E-12 

UNCERTAINTY**! FOR DRIFT BIAS 1 

(5,5) 


4.E-12 

uncertainty**! for drift bias 2 

(6,5) 


4.B-12 

UNCERTAINTY**! FOR DRIFT BIAS 3 
ALL OTHER ELEMENTS ARE ZERO, 

ADBIAS(3) 

R«4 

3*0,0 

INITIAL GYRO DRIFT RATE BIASES IN THE 
BODY FRAME AT QTIME (RADIAN/SEC) 

(1) 



X-AXIS BIAS 

(2) 



Y-AXIS BIAS 

(35 



Z-AXIS BIAS 

AGBIAS(6) 

RMB 

6*0,0 

INITIAL GYRO DRIFT RATE BIASES AT THE 
time QTIME (0E6/SEC) 

(I) 



BIAS FOR THE I-IH CHANNEL, I*1 TO 6 
corresponds to channels Ai, A!, Bl, 
B2, Cl, C2, RESPECTIVELY, 

GC(3,3,8) 

R«4 


GYRO ALIGNMENT MATRICES FOR THE GYRO 
TO SPACECRAFT FRAME, 

(I,J,K5 



iBl.Sf J»l,3 IS THE MATRIX 

FOR THE K-TH GYRO CONFIGURATION, 

Kal.8 

ALL MATRICES ARE IDENTITY MATRICES. 

GN0ISE(2,6) 

R*4 


NOISE ASSOCIATED WITH THE GYRO 
MEASUREMENTS FOR ALL SIX CHANNELS, 

(1,J) 


3.E-9 

GYRO RATE NOISE FOR THE J-TH CHANNEL 
(RA0IAN**2/SEC0ND) 

(2,J5 


5.E-21 

GYRO DRIFT RATE-RATE NOISE FOR THE 
J-TH CHANNEL (RAOIAN**2/SECOND**3) 

THE CHANNEL ASSIGNMENT 18 FOR J«1 TO 6, 
THE CHANNEL ARC Al, A2, Bl, B2, Cl, C! 

DRPTOL 

R«4 


DATA DROPOUT TIME INTERVAL (SECONDS) 
FOR ACCOMULATING GYRO DATA, 

NOT USED, 
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TGYLrM(2,2) 

T«a 


LIMIT FOR GYRO COUNTS (COUNTS) 

(1,1) 


600 

LOWER LIMIT. N0HINAL(L0W RATE) MODE. 

(1,2) 


800 

UPPER LIMIT. NOHINAL(LOW RATE) MODE. 

(2,1) 


600 

lower LIMIT. MANEUVERCHIGH RATE) MODE. 

(2,2) 


800 

UPPER LIMIT. MANEUVERCHIGH RATE) MODE. 

RE0N(3) 

R*4 


TOLERANCES FOR REDUNDANT GYRO CHANNEL 
OUTPUTCRADXAN/SECOND). AADS SENDS AN 
ERROR MESSAGE IF THE DIFFERENCE IN RATE 
BETWEEN TWO SEPARATE CHANNELS ON THE 
SAME AXIS EXCEEDS THE TOLERANCE. 

(1) 


.48R-5 

X AXIS! Al, C2 channels 

(2) 


.48E>S 

Y AXXSt 81, A2 channels 

(3) 


.48E»5 

Z AXISI Cl, 82 channels 
A,B,C ARE THE THREE, TWO AXIS GYROES 
A1,B1,C1 is the PRIMARY CONFIGURATION 
C2,A2,B2 IS THE BACKUP CONFIGURATION 

TROLL 

T*4 


NOT USED, 

NAXGYR 

I»4 

8388667 

MAXIMUM GYRO COUNTS 

IGYCON 

I«4 

1 

GYRO CONFIGURATION 


1 ■ Al« ai, Cl I PRIMARY CONFIG. 

2 ■ Al, 81, B2 

3 ■ Al, A2, Cl 

4 ■ Al, A2, 82 

5 > C2, 81, Cl 

« ■ C2, 81, 82 

7 ■ C2, A2, Cl 

8 ■ C2, A2, 82 

TCDTAB(3,9) I«2 135 GYRO CHANNEL COMBINATION TABLE 

134 REPRESENTS THE 8 POSSIBLE CONFIGURATIONS 

1 2 S LET THE CHANNELS Al, A2, Bl, B2, Cl, AND 

124 C2 BE REPRESENTED BY THE NUMBERS 1 THRU 

635 6, RESPECTIVELY. THEN THE GIVEN DEFAULTS 

634 REPRESENT THE 8 POSSIBLE CONFIGURATIONS 

625 WITH THE PRIMARY CONFIGURATION GIVEN BY 

624 IGYCON. THE BACKUP CONFIGURATION 18 THE 

759 DIFFERENCE BETWEEN THE 9TH SUBARRAY AND 

THE PRIMARY CONFIGURATION. 

THIS PARAMETER IS INTERNALLY USED BY 
AADS. IT IS NOT A CONTROL PARAMETER 
AND SHOULD NOT BE CHANGED. 

CONVERSION CONSTANTS FOR CONVERTING 
THE GYRO counts TO ANGLE C DEGREE/COUNT) 
CONVERSION FACTOR FOR THE 1«TH CHANNEL 
FOR THE LOW RATE MODE. 

0.1388889B-4 DEGREE/COUNT OR 
O.OS ARC-SECOND/SECOND 

(T,2) CONVERSION FACTOR FOR THE I*TH CHANNEL 

FOP THE HIGH RATE MODE. 

.2222222E»4 OEGREE/COUNT OR 
0,8 ARC-SECOND/SSCOND, 

THE channel assignment IS Xal TO 6 
FOR channels Al, A2, Bl, B2, Cl, C2, 
RESPECTIVELY. 


CGYR0(6,2) R*4 

( 1 , 1 ) 
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4.4.3 

STAR DATA PROCESSING AND STAR IDENTIFICATION 
PARAMETERS 

VARIABLE 

TIPE DEPAULT 

DESCRIPTION 

RN(2,2) 

R*fl 

MODEL MEASUREMENT N0I8E(RADZAN>. 


THIS Z8 THR LONER BOUND ON THE NOISE. 
ACTUAL NOISE IS COMPUTED AS THE MAX 
nr RN AND THE GROUP CLUMP SIZE. SEE 
GCLUMP BELOW. 


C1,J) 


0,0001 

MEASUREMENT NOISE fOR THE J-TH 
TRACKER! Jal, 2) THAT IS USED FOR THE 
(X/Z) MODEL DURING UPDATE, HERE, X,Y,Z 
are the 3 COMPONENTS OP THE OBSERVED 
UNIT STAR VECOTR. 

(2,J) 


0.0001 

MEASUREMENT NOISE POR THE J-TH 
TRACKER (jBl, 2) THAT IS USED POR THE 
(Y/Z) MODEL DURING STATE UPDATE. 

TRC3,3,2) 

ci.j.n 

(1,J,2) 

R«4 


SPACECRAFT TO FHST ROTATION MATRICES 
(lBl,3), CJal,3) ARE THE 9 ELEMENTS 
OP THE PHSTl TO BODY ROTATION MATRIX 
-.7865943 .6174676 -.37S1331E-06 

.1656166 .21^0699 ,9633263 

.5948228 ,7577488 -.2683329 

(lal,3), CJal,3) ARE 9 ELEMENTS OP 
OP THE SPACECRAFT TO PH8T2 MATRIX! 
.7865963 .6174676 0.0 

,1656866 -.2110699 -.9633263 

-.5948228 .7577488 -.2683329 

IHLIM(2,2) 

IM4 


UPPER/LOHER LIMITS POR STAR H 
POSITION (COUNTS) 

(1,1) 


2047 

UPPER LIMIT POR PHSTl 

(2,1) 


-2047 

LOWER LIMIT POR PHSTl 

(1,2) 


2047 

UPPER LIMIT POR PH8T2 

(2,2) 


-2047 

LOWER LIMIT POR PHST2 

IVLIM(2,2) 

I«4 


UPPER/LOWER LIMITS POR STAR V POSITION 
(COUNTS) 

(1,1) 


2047 

UPPER LIMIT POR PHSTl 

(2,1) 


-2047 

LOWER LIMIT POR PHSTl 

(1,2) 


2047 

UPPER LIMIT POR PHST2 

(2,2) 


-2047 

LOWER LIMIT POR PHST2 

VILIM(2,2) 

R*4 


UPPER/LOHER LIMITS POR STAR INTENSITY 
(VOLTS) 

(1,1) 


999.0 

UPPER LIMIT POR PHSTl 

(2,1) 


.0001 

LOWER LIMIT POR PHSTl 

(1,2) 


999.0 

UPPER LIMIT FOR PHST2 

(2,2) 


.0001 

LOWER LIMIT POR FHST2 
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VTT.IMC?,?) R*4 

(1,13 

(2,1) 

(1,2) 

(2,2) 

999,0 

.0001 

999,0 

,0001 

UPPER/LOWER MMIT FOR STAR TEMPERATURE 
(VOLTS) 

UPPER LIMIT FOR FHSTl 
LOWER LIMIT FOR FHSTl 
UPPER LIMIT FOR FHST2 
LOWER LIMIT FOR FHST2 

CALHVTf 19,2,2)R*4 


STAR POSITION CALIBRATION PARAMETERS TO 
CORRECT FHST DATA FOR TEMPERATURE 

(T,t,l) 


1^1 TO 19, ARE 19 elements FOR FHSTl 
FOR H COORDINATE. 

CALHVT(2,1,1)«1., OTHER ELEMENTS ZERO 

(T,l,2) 


T«l,19 ARE THE 19 PARAMETERS FOR FHST2 
FOR H COORDINATE, 

CALHVT(2,l,2)Bl., OTHER ELEMENTS ZERO 

(T,2,l) 


Ial,19 ARE 19 PARAMETERS FOR FHSTl 
FOR V COORDINATE 

CALHVT(3,2,1)b1.. other ELEMENTS ZERO 

(T,2,2) 


Ial,19 ARE 19 PARAMETERS FOR FHST2 
for V COORDINATE 

CALHVTC3,2,2)al., OTHER ELEMENTS ZERO, 

eALHVl(l9,2,2)R*4 


STAR POSITION CALIBRATION PARAMETERS TO 
CORRECT FHST DATA FOR INTENSITY 

(T,l,l) 


iBl TO 19, Are 19 ELEMENTS FOR FHSTl 
FOR H COORDINATE, 

CALHVI (2,1, !)■!,, OTHER ELEMENTS ZERO 

(T,l,2) 


lal,19 ARE the 19 PARAMETERS FOR FH8T2 
FOR H coordinate', 

CALHVI ( 2,1, 2 )al., OTHER ELEMENTS ZERO 

(T,2,l) 


Ial,i9 ARC 19 PARAMETERS FOR FHSTl 
FOR V COORDINATE 

CALHVI (3, 2, Dal., OTHER ELEMENTS ZERO 

(1,2,2) 


Ial,19 ARE 19 PARAMETERS FOR FHST2 
FOR V COORDINATE 

CALHVI (3, 2, 2 )al,, OTHER ELEMENTS ZERO, 

CTCIVT(2,2) R*4 

(1,J) 

(2,J) 

1.0 

0,0 

COUNT TO VOLT CONVERSION FOR TEMP* 
NATURE ASSUMMING 

VOLTS a KIMCOUNTS * K2, WHERE Kl, AND 
R2 ARC CONSTANTS 
K1 IN (VOLT/COUNT), R2 IN (VOLT) 
CONSTANT K1 FOR THE J-TH TRACKER, Jai,2 
constant K2 FOR THE J-TK TRACKER, Jal,2 

CTOVTC2,2) R*4 
(1,J) 

1.0 

COUNT TO VOLT CONVERSION FOR STAR 
INTENSITY ASSUMING 

VOLTS a Kl»COUNTS K2, WHERE Kl, AND 
K2 ARC CONSTANTS, 

Kl IN (VOLT/COUNT), K2 IN VOLT 
CONSTANT Kl FOR THE J-TH TRACKER, Jal,2 
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(9,vT) 


0,0 

COMSTAMT K2 FOR THE J-TH TRACKER, J«l,2 

thf:tah(2,2) 

R*4 


STAR camera H POSITION COUNTS TO DEGREE 
CONVERSION constants ASSUMING 
DEGREE « K1*COUNT K2 

K1 IN (DEGREE/COUNT), K2 IN (DEGREE) 




CONSTANT K1 FOR THE J-TH TRACKER, J»l,2 
(1,J) > 3.41052SE.5 

(2,J1 


0,0 

CONSTANT K2 FOR THE J-TH TRACKER, J«l,2 

THF:TAVf2,2) 

R»4 


STAR CAMERA V POSITION COUNTS TO DEGREE 
CONVERSION CONSTANTS ASSUMING 
DEGREE B KlFCOUNTS -f K2 




CONSTANT K1 FOR THE J-TH TRACKER, Jb1,2 
K1 IN (DEGREE/COUNT), K2 ?N (DEGREE) 
(1,J) B 3.410525E-5 

(2,J) 


0.0 

CONSTANT K2 FOR THE J-TH TRACKER, Jal,2 

T0MC2) 



TOLERANCE FOR THE SUCCESSIVE DIFFERENCE 
IN INTENSITY (VOLTS) DURING STAR GROUP 
FORMATION, 

(1) 


5,0 

FHSTl 

i2'l 


5,0 

FHST2 
NOT USED, 

TOLPt2,2) 

R44 


TOLERANCE FOR THE SUCCESSIVE DIFFERENCE 
IN POSITION (COUNTS) 

A NEW GROUP IS STARTED WHEN THE DIFF, 
EXCEEDS THE TOLERANCE 
NOTE THAT NEW GROUPS ARE ALWAYS 
STARTED AFTER AN UPDATE, EVEN IF THE 
TOLP TOLERANCE CAN BE SATISFIED, 



50,0 

TOLERANCE FOR H COUNTS FOR THE J-TH 
TRACKER, JBl,2 

(2,J) 


50,0 

TOLERANCE FOR V COUNTS FOR THE J-TH 
tracker, JBl.2, 

TTRK(2) 

R»4 


MAXIMUM track group TIME (SECONDS) 

NEW OBSERVATIONS FROM THE STAR ARE 
ARE REJECTED UNTIL NEXT UPDATE IF SAME 
STAR CONTINUES TO BE TRACKED AFTER 
TTRK SECONDS. 

fn 


20,0 

FHSTl 

(2) 


20,0 

FHST2 

TTRK(2,2) 

1*4 


MININUM/MAXIHUM NUMBER OF TRACK POINTS 
NECESSARY FOR A TRACK GROUP FORMATION 
WHEN THE MAXIMUM POINTS ARE COLLECTED 
FOR the current GROUP, AADS DISCARDS 
THE NEW STAR OBSERVATIONS IF SAME STAR 
CONTINUES TO BE TRACKED, 

SEE TOLP, TTRK ABOVE, 

(l.J) 


10.0 

MINIMUM FOR THE J-TH TRACKER, Jal,2 

(2,J5 


60, 0 

MAXIMUM FOR THE J-TH TRACKER, Jal,2 

TGMIN(2) 

R«4 


minimum TIME BETWEEN TWO TRACKER GROUPS 
TO 8EPERATE OBSERVED STARS (SECONDS), 

(1) 


0.3 

TRACKER 1, 

(?) 


0,3 

TRACKER 2, 

TRS(2) 

R*4 


TIME INTERVAL OF CONSECUTIVE 
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ORIGINAL PA@la 
OF POOR QUAirnf 


(1) 

(?) 


UNACCEPTABLE RAW STAR TRACKER DATA 

peyond which error message will be sent 

(SECONDS) 

120.0 PHSTl 

120.0 FHST2 


GCLU'*P(2) RP4 


(1) 0,5 

(2) 0,5 


TOLERANCE FOR TRACK GROUP CLUMP SIZE 
A STAR GROUP IS NqT VALID IF THE 
OBSERVED CLUMP SIZE EXCEEDS THE TOLE* 
RANCE, THE CIWRVED CLUMP SIZE IS AN 
INDICATION 0^ THE TOTAL NOISE IN THE 

average observed star vector, this is 

THE MOISE(ERROR) DUE TO STATE PROPAGA* 
TION PLUS the noise in the STAR DATA. 
(DEG) 

FHSTI 

FHST2 


ITNCID 144 0,2 ATTITUDE UNCERTAINTY CRITERIA FOR 

CHOOSING STAR IDENTIFICATION METHOD 
(DEG) 

COMPUTED UNCERTAINTY LESS THAN OR 
EQUAL TO UNCID, THEN USE DIRECT STAR 

matching method 

COMPUTED UNCERTAINTY GREATER THAN 
UNCID, then use the PAIRWISE STAR 

matching method 


TSTRMN T*4 


MINIMUM NUMBER OF TRACK GROUPS FOR 
ATTEMPTING LAST-MINUTE STAR 
IDENTIFICATION OR UPDATE 


T5TR0S(2) T*4 

( 1 ) 1 

(2) 3 


DESIRED NUMBER OF TRACK GROUPS FOR 
attempting IDENTiriCATlOM 
FOR DIRECT IDENTIFICATION METHOD 
PAIRWISE IDENTIFICATION METHOD 


T0LINT(2) 


( 1 ) 

( 2 ) 


STAR IDENTIFICATION MAGNITUDE TOLERANCE 
TO COMPARE THE STAR MAGNITUDES FROM THE 
STAR CATALOG AND OBSERVATIONS 
0.5 TRACKER 1 

0,5 TRACKER 2 


SMAG(2,2) R«4 

(1,J) -1.0 

(2,J) 5,0 


STAR INTENSITY TO MAGNITUDE CONVERSION 
ASSUMING 

MAGNITUDE ■ K1«L0G(INTEN8ITY) * K2. 
CONSTANT K1 FOR THE J-TH TRACKER, Jmi ,2 
CONSTANT K2 FOR THE J-TH TRACKER, J»l,2 


DMWIND 


RM4 0,05 


DIRECT MATCH OBSERVATION TOLERANCE 
OR WINDOW SIZE (DEGREES!, ALL STARS 
IN A WINDOW centered ON THE AVERAGE 
OBSERVED STAR VECTOR ARE CANDIDATES 


DTSUN RM4 1.0 INTERVAL FOR COMPUTING AN AVERAGE SUN 

VECTOR FOR ABERRATION CORRCCTION(8ECONDS 
SV(I) « SUN VECTOR AT TIME T IS GIVEN By 
SV(T)a (SV(T4.DTSUN)+SV(T-0TSUN) )/2*DT8UN 


DliTP R*4 0,5 MINIMUM SEPARATION BETWEEN THE INITIAL 

PAIR DURING PAIRWISE NATCHING(DEGREE) , 
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OR!GS^"^L TA' . . , . 

OF POOR QOALi'i'oi 

h path op ossepvpd stars will be 

TNITTALLY SELECTED AND IDENTIFIED. THE 
RENAXNXNC OBSERVED STARS WILL THEN BE 
matched against these two stars. DXSTP 

IS THE MINIMUM SEPERATION REQUIRED 
FOR the first PAIR. 


PMWIMD 

R*4 

o 

• 

CM 

WINDOWSIZE for pairwise KaTCHING(DEG) 
SEC OMWIND ABOVE. 

MDMW 


2 

MULTIPLICATION FACTOR FOR COMPUTING 
direct MATCH WINDOW SIZE USING THE 
CURRENT ATTITUDE UNCERTAINTY (NO UNITS) 

MPMW 

1*4 

2 

MULTIPLICATION FACTOR FOR COMPUTING 
PAIR-WISE match window SIZC(PMWIND) 
USING ATTITUDE UNCERTAINTY (NO UNITS) 

PTOL 

R«4 

CM 

• 

O 

PAIRWISE MATCHING ARC-LENGTH TOLERANCE. 


arc-length separation is computed for a 

PAIR OF OBSERVED STARS. ARC-LENGTH 
IS ALSO computed FOR A CANDIDATE PAIR 
corresponding to THE OBSERVED PAIR. 

THE candidate PAIR IS REJECTED IF THE 
difference IN ARC LENGTH EXCEEDS THE 
TOLERANCE. 

(DEGREE) 


lUNIRD 

T44 

0 

UNIQUE MATCH REQUIREMENT FLAG 
FOR DIRECT MATCH IDENT1FICATI0N(N0 UNIT) 
■0. UNIQUE MATCH NOT REQUIRED 
■1. UNIQUE MATCH REQUIRED 

lUNlOP 

144 

0 

UNIQUE MATCH REQUIREMENT FLAG FOR 
PAIR-WISE match IDCNTIFICATION(NO UNIT) 
■0. UNIQUE MATCH NOT REQUIRED 
>1. UNIQUE NATCH REQUIRED 

idoubd 

T*4 

0 

FLAG FOR using DOUBLET STAR8(N0 UNIT) 
DURING STAR IDENTIFICATION 
■0. NO 
al. YES 

MNUMO 

I»4 

1 

MINIMUM NUMBER OF IDENTIFIED STARS FOR 
DIRECT identification TO BE 
SUCCESSFUL (NO UNIT) 

MNIIMP 

144 

3 

MINIMUM NUMBER OF IDENTIFIED STARS FOR 

pair-wise identification to be 

successful (NO UNIT) 

pctd 

R44 

500 

MINIMUM PERCENTAGE OF IDENTIFIED STARS 

FOR DIRECT MATCH TO BE 

SUCCESSFUL 

PCTP 

R44 

70.0 

MINIMUM PERCENTAGE OF IDENTIFIED STARS 
FOR PAIR-WISE match TO BE SUCCESSFUL 
ISTRDS(2)b 3. MNUMpaS. PCTDaTO.O 
THAT AADS WILL USE A MINIMUM OF 
3 STARS FOR PAIRWISE HATCH 
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ORIGINAL PAGE i?f 
OF POOR QUALITY 


4.4.4 OCCULTATION PREDICTION PARAMETERS 


VARI'IBLE 

typf: 

DEFAULT 

OESCRIPTTON 


CS'fNf8> 



CONSTANTS FOR SOLAR EPHEHERIS 
CALCULATION 


CMnOM(flJ 



CONSTANTS FOR LUNAR BPHEMCRXS 


RAnins(25 

a) 


4378.4 

1738,2 

RADII (KILOMETERS) 

EARTH 

MOON 


0BTAS(2) 

(t) 

(9) 


100,0 

20,0 

NIAS ON THE RADIUS (KILOMETERS) 

EARTH 

MOON 


F0VSTC2J 

(I) 

R44 

4.0 

FIELD OF VIEW OF THE STAR CAMERA 
FOR the I-TH STAR CAMERA, I»l,2 

(DEGREE 

0IA5TC2) 

(T) 

944 

0,2 

DIASES ON THE FIELD OF VIEW (DECREE 
DIAS FOR THE I»TH STAR TRACKER, Xill,2 

MODEGY 

r*4 

1 

DUMMY variable USED IN THE CREATION OF 
temporary global COr^MON AREAS, THIS 
VARIABLE MUST BE THE LAST ONE IN THE 
CLUSTER FOR PROPER MAPPING 

4 . 5 AADS 

ERROR 

MESSAGES 




AADS may generate error messages during execution. These 
error messages are of two types: critical and noncritical. 

In both cases, AAds takes a predefined action (error han- 
dling). and continues execution. For critical errors (for 
example, star identification not possible) , ground action in 
the form of uplink of new values for AADS control variables 
is expected. The errors are transmitted to the ground as 
messages. The message header portion contains the error 
number and the data portion may contain one or more numbers, 
depending on the specific error. Error text is stored on 
the ground in a data set on the VAX to save AADS space and 
limit the message length. GSS decodes the error message, 
selects error text corresponding to the error number from 
the error message data set, and displays it on the output 
device. The error text explains the nature of the error and 


the optional numbers contained in the error message give 
specific information about the error. 

For example r the error message 601 contains the numbers 

720.01 and 2. The error text printed by GSS explains that 
the star tracker 2 did not see any stars for the last 

720.01 seconds. If the ground control repeatedly receives 
an error message indicating that stars cannot be identified, 
the operator uplinks a new estimate of the spacecraft atti- 
tude because the current estimate of the spacecraft attitude 
is incorrect for some reason. 

AADS error message numbers are allocated by processes as 
follows: 

Error Number 

000 to 099 
100 to 199 
200 to 299 
300 to 399 
400 to 499 
500 to 599 
600 to 699 
700 to 799 
800 to 899 
900 to 999 

4.5.1 SYSTEM EXECUTIVE MESSAGES 

Number 000: In routine UPSTAT. A command was received and 

was considered to be invalid. The AADS was already in the 
processing mode directed by the command, or the command 
number is out of range. This is a noncritical error. The 
executive process will continue in the current processing 
mode. 


Process 

EXEC 

DCAP 

INPUT 

SENS IN 

GYPROC 

PROPAG 

S TRACK 

STARID 

UPDATE 

OUTPUT 



Description 


Type 


1 

1*4 

Error number 

5 

R*8 

Current simulation time (YYMMDD.HHMMSS) 

13 

1*4 

Command number. Valid numbers are: 

1- -START 

2- -STOP 

3- HALT 

4 - -RESUME 


Number 001: In routine TIMEUP. The time limit for an atti 

tude update was exceeded. This is a critical error. The 
executive process will continue attempting an attitude up- 
date. 

Byte Type Description 

1 1*4 Error number 

5 . R*8 Current simulation time (YYMMDD.HHMMSS) 


Number 002: In routine TIMEUP. A process scheduled to exe- 

cute at this time has not completed or returned from its 
previous execution. This is a noncritical error. The 
executive will schedule the process for its next execution. 


Byte 

1 

5 

13 


Type : Description 

1*4 Error number 

R*8 Current simulation time (YYMMDD.HHMMSS) 

1*4 Number of scheduled process: 

3- -SENSIN 

4- -GYPROC 

5- -PROPAG 

6- STRACK 

7 - -STAR ID 

8- -UPDATE 


Number 003: In routine TSKDNE. A completion of a maneuver 

was detected and the star data processing is in a halted 
mode. This is noncritical error. The executive will con- 
tinue normal gyro processing and propagation. 
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Byte 

1 

5 


Description 


Type 

1*4 Error number 

R*8 Time or error 

4^5.2 INPUT/OUTPUT MESSAGES 

Number 100: In routine DCAP. Data with an invalid synchro 

nization (sync) byte(s) was read. This is a noncritical 
error. The data capture process ignores the data and per- 
forms another read on the line. 

Byte- Type Description 


1 

1*4 

Error number 

5 

R*8 

Time tag on erroring record (YYMMDD.HHMMSS) 

13 

1*4 

Record number in transmission from header 
of erroring record 

17 

L*1 

Value of first sync byte 

18 

L*1 

Value of second sync byte 


Number 101: In routine QLONG. Uplinked data was lost due 

to a full queue. This is a noncritical error. The input 
process will validate and store the data that was success- 
fully queued. 

Byte Type Description 


1 

1*4 

Error 

number 


5 

R*8 

Time tag on lost 

record (YYMMDD.HHMMSS) 

13 

1*2 

Record 

number in 

block 

15 

1*2 

Record 

number in 

transmission 

17 

1*2 

Block 

number in 

transmission 


Number 102: In routine DCAP. An unidentified command or 

data was read. The erroring record has an invalid INTYPE 
value (and valid sync byte values) . This is a noncritical 
error. The data capture process ignored the data and per- 
forms another read on the line. 
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Byte Type Description 


1 

1*4 

Error number 

5 

R*8 

Time tag on erroring record ( Y YMMDD . HHMMSS ) 

13 

1*4 

Record number in transmission from header 
of erroring record 

17 

L*1 

Erroring INTYPE value 


Number 103: In routine STOEPH. Ephemeris data with invalid 

header variables was read. Either the record number in the 
transmission, or the number of ephemeris points, is in- 
valid. This is a noncritical error. This record will be 
ignored and any data successfully queued prior to this will 
be validated by the input process. 


Byte 

Type 

Description 


1 

1*4 

Error number 


5 

R*8 

Time tag on erroring record (seconds since 



9-1-57) 


13 

1*4 

Record number in transmission from header 



of erroring record 


17 

1*4 

Number of ephemeris points 


Number 

201: 

In routine INEPH. The magnitude of ephemeris 

data that was 

read is invalid. This is a noncritical 


error . 

Ephemeris elements that passed . validation prior 

to 

this will be 

kept. The erroring ephemeris element and , 

any 

following ephemeris elements will be discarded. 


Byte 

Type 

Description 


1 

1*4 

Error number 


5 

R*8 

Time of erroring ephemeris element (in 

sec- 



onds since 9-1-57) 


13 

R*4 

Position vector magnitude 


17 

R*4 

Velocity vector magnitude 
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Number 202: In routine HEADER. The running record or block 

number in the transmission is invalid. This is noncritical 
error. The uplink data is discarded. 

Byte Type Description 


1 

1*4 

Error number 



5 

R*8 

Time tag 

on erroring record ( y YMMDD . HHMMSS ) 

13 

1*2 

Expected 

block number 



15 

1*2 

Expected 

record number 

in 

transmission 

17 

1*2 

Received 

block number 



19 

1*2 

Received 

record number 

in 

transmission 


Number 203: In routine HEADER. The running record number 

in the block is invalid. This is a noncritical error. The 


uplink 

data is 

discarded . 


Byte 

Type 


Description 

1 

1*4 

Error number 

5 

R*8 

Time tag 

on erroring record ( YYMMDD. HHMMSS ) 

13 

1*2 

Expected 

record number in block 

15 

1*2 

Received 

record number in block 

17 

1*2 

Received 

sion 

running block number in transmis- 

19 

1*2 

Received 

sion 

running record number in transmis- 


Number 204: In routine HEADER. The number of bytes of data 
indicated in the header exceeds the maximum. This is a non- 
critical error. The uplink data is discarded. 

Byte Type Description , 


1 

1*4 

Error number 


5 

R*8 

Time tag on erroring record ( YYMMDD . HHMMSS ) 

13 

1*2 

Number of bytes of data 


15 

1*2 

Running record number in 

block 

17 

1*2 

Running block number in 

transmission 

19 

1*2 

Running record number in 

transmission 
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Number 205; In routine HEADER. The time tags on received 
records are not sequential. This is a noncritical error. 

The uplinked data is discarded. 

Type Description 

1*4 Error number 

R*8 Time tag of error ing record ( YYMMDD. HHMMSS) 

R*8 Time tag of previous record (YYMMDD. HHMMSS) 


Number 206: In routine INFULL. A COMMON area was over- 

filled with uplinked data. This is a noncritical error. 

The common area following the one indicated may be damaged. 


Byte 

Type 

Description 

1 

1*4 

Error number 

5 

R*8 

Time tag on last record (YYMMDD. HHMMSS) 

13 

1*4 

Number indicating the last overfilled STATIC 
COMMON area: 

1- -STAT1 

2- -STAT2 

3 - STAT3 

4- -STAT4 

4.5.3 

GYRO DATA 

PROCESSING MESSAGES 


Number 401: In routine GYPROC. Power off detected in some 

channels. This is a critical error if more than one channel 
power is off. Otheirwise,. GYPROC will continue execution. 


Byte 

Type 


Description 

1 

1*4 

Error 

number 

5 

R*8 

Error 

time (YYMMDD. HHMMSS) 

13 

1*2 

Error 

code: 


= 1, channel 1 off 
*1= 2, channel 2 off 
= 3/ channel 3 off 
=? 5, channels 1,2 off 
= 6, channels 1,3 off 
= 9, channels 2,3 off 
- 18, channels 1,2,3 off 
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Byte 

1 

5 

13 


Number 402; In routine GYPROC. Saturation detected for 
channels. GYPROC will use the saturation value to compute 
body rates and continue execution. 

Byte Type Description 


1 

1*4 

Error number 

5 

R*8 

Error time (YYMMDD.HHMMSS) 

13 

1*2 

Number of saturations in first given 
channel 

15 

1*2 

Number of saturations in second 
given channels 

17 

1*2 

Number of saturations in third given 
channel 

Number 403 

; In 

routine GYPROC. Glitch (large noise pulse) 

detected. 

This 

is a noncritical error. GYPROC will not use 

the noisy 

data/ 

but will continue execution. 

Byte 

Type 

Description 

1 

1*4 

Error number 

5 

R*8 

Error time (YYMMDD.HHMMSS) 

13 

1*2 

Error code. See the error codes given 


for error 401 


Number 404; In routines GYPROC and PROPAG. Invalid gyro 
configuration number detected. This is a critical error. 
GYPROC/PROPAG will not process data. Uplink new valid gyro 
configuration number between 1 and 9. 

Byte Type Description 

1 1*4 Error number 

5 1*4 Gyro configuration number 


Number 501; In routine PROPAG. The difference in rate be- 
tween the primary and the secondary channels exceeds the 
specified tolerance. PROPAG will continue processing data 
but the state propagation may give incorrect attitude. 
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1 

Type 


Description 

i*4 

Error 

number 

5 

R*8 

Error 

time (YYMMDD.HHMMSS) 

13 

1*2 

Gyro 

channel number 


Number 502: In routine PROPAG. The incremental time for 

the given channel was zero, probably due to invalid gyro 
data for that channel. PROPAG will use the last valid rate 
and continue execution. 


Byte 

Type 

Description 

1 

1*4 

Error number 

5 

R*8 

Error time (YYMMDD.HHMMSS) 

13 

1*2 

Channel number 

Number 

503; In routine PROPAG. The propagation time is 

zero. 

PROPAG will continue 

execution, but will use the last 

valid 

gyro rates. 


Byte 

Type 

Description 

1 

1*4 

Error number 

5 

R*8 

Error time (YYMMDD.HHMMSS) 

13 

R*8 

Propagation time in seconds 


4.5.4 STAR DATA PROCESSING MESSAGES 

Number 601: In routine MAGN. Star tracker 1 or 2 invalid 

data time interval exceeds specified tolerance. This is not 
a critical error and AADS will continue processing. The 
error has probably occurred because there are no stars in 
the field of view (most likely), or the star data are fail- 
ing limit checks. Check the limits on H and V counts and 
observed intensity. 

Byte Type Description 

1 1*4 Error number 

5 R*8 Last valid data time (YYMMDD.HHMMSS) 

13 R*4 Invalid data interval (seconds) 
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There are no error messages in the STARID process. 

Number 801: In routine UPDATE. Error detected during state 

update. Execution will continue, but the current star ob- 
servation will not be used. 



1 1*4 Error number 


5 R*8 Error time ( YYMMDD. KHMMSS) 

13 1*2 =1# Denominator zero in computing 

model residuals 
= 2, Number of elements in the 
state vector is incorrect 

4.6 AADS MESSAGE FORMATS 

AADS communicates with the external world by means of mes- 
sages. A message usually contains a header portion followed 
by a data portion. The header contains flags describing 
data that follow. In addition, the header contains a sync 
(synchronization) byte and other accounting information to 
enable detection of errors errors in message transmission. 

The majority of messages is 256 bytes in length. However, 
the annotation report and the ephemeris request are 40 bytes 
long and do not have a standard header. The uplink messages 
are transmitted by GSS to OBC(OSS) and then . retransmitted by 
OBC(OSS) to AADS. AADS output also goes to OBC(OSS); 

OBC(OSS) then retransmits the AADS messages to the ground, 
except for the ephemeris request, which is used by OBC(OSS) 
to generate the requested ephemeris. GSS decodes the AADS 
output and generates formatted, hardcopy output for operator 
evaluation. The following terms are used to describe mes- 
sage formats: 

• Header--Most significant bytes of the message (us- 
ually 20) containing the data type information, 
sync bytes, and other accounting information. 
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• Record--A 20-byte header plus data plus filler to 
comprise 256 bytes. Words record and message are 
used interchangeably. Filler bytes contain 
binary 1 bits. 

• Block--A collection of records. For example, the 
update report is sent as a block of three records. 

• Transmission--A collection of two or more blocks in 
which the last block is the end-of -transmission 
block (EOT) . EOT contains binary 1 bits. 

The following pages describe the various message formats in 
detail. 

4.6.1 GENERAL HEADER (UPLINK/DOWNLINK) FORMAT 

The header size is 20 bytes long and is used for all uplink 
messages. It is also used for the raw sensor data report, 
the update report, and the activity log report. The general 
header format is given below. Byte 1 means the most sig- 
nificant byte. 


Byte 


Variable 

Number 

Type 

Value 

Description 

SYNCl 

1 



Byte 

88 

Sync byte (later spacecraft 
ID) 

INTYPE 

2 



Byte 


Type of input : 
= 1, data 
= 2, command 

INDATA 

3 



Byte 


Type of data or command 

NBLOCK 

4 



Byte 


Running number of this 
record in block 

lAREA 

5 



Byte 


Data area number for 
insertion or report 

SYNC2 

6 



Byte 

103 

Second sync byte 

NTRAN 

7 

to 

8 

1*2 


Running number of this 
record in transmission 

IB LOCK 

9 

to 

10 

1*2 


Running number of this 


block in transmission 
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Byte 

Variable Number Type Value Description 


NSIZE 

11 

to 

12 

1*2 

Number of bytes used in the 
data portion of the record 

TTRAN 

13 

to 

20 

R*8 

Time of transmission (GMT) 
YYMMDD.HHMMSS 


4.6.2 COMMANDS AND UPLINK DATA 

GSS sends commands to AADS with a standard header (see Sec- 
tion 4.6.1) with INTYPE - 2 and INDATA = 3. The command 
number is contained in the first four bytes (1*4 variable 
ICMD) following the header. The following commands are spe- 
cified: 

ICMD = 1--START 
ICMD = 2--STOP 
ICMD = 3--HALT 
ICMD = 4 --RESUME 

OBC(OSS) receives all uplink messages from GSS, and retrans- 
mits appropriate messages to AADS. GSS uplinks new tables 
(new values for AADS control parameters) , using a standard 
header with INTYPE = 1. The new values are stored in AADS 
COMMON areas using INDATA and NSI2E values in the header. 

For example, INDATA = 2 and NSIZE = 236 means to store 
236 bytes from the data area of the message in the COMMON 
area /STAT3/. Because the whole COMMON area must be modi- 
fied during a single transmission, there will be a block of 
three consecutive records in the transmission with 
INDATA = 2. Records within the block must be in the proper 
order to ensure a correct update. The data area from the 
last record in the block may be partially filled (NSIZE < 
236) . If all four AADS COMMON areas are updated, the trans- 
mission to AADS will consist of four blocks, each block con- 
taining one or more records. The header for each record 
will have INTYPE= 1 and the proper value of INDATA as given 
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1 


1 


Gyro processing parameters 
(/STAT2/ global COMMON values) 

2 1 Star processing parameters (/STAT3/ 

global COMMON values) 

3 2 Commands to AADS 

4 1 Process scheduling parameters and 

priorities (/STATl/ global COMMON 
values) 

5 1 Orbital elements (to OSS only) 

6 1 Occultation prediction parameters 

(/STAT4/ global COMMON values) 

20 1 Error messages from AADS to GSS 

4.6.3 SPACECRAFT EPHEMERIS FROM OSS TO AADS 

AADS periodically makes requests for spacecraft ephemeris to 
OBC(OSS). The format of this request is described later in 
this section. OBC(OSS) generates the requested ephemeris 
and sends it to AADS as a transmission containing six rec- 
ords followed by the EOT record. Each record has a header 
with INTYPE =5. In addition, the header for each record 
contains the SYNCl byte and the running number of the record 
(ENTRAN ) , but does not contain other variables in the stand- 
ard header. Instead, the header contains the ephemeris 
start time, number of points, and time interval between 
points for verification. Nominally, the ephemeris transmis- 
sion contains 20 position and velocity vectors each, and can 
cohtain a maximum of 29 of these vectors. The data area of 
records 1 to 3 contain the spacecraft position vector com- 
ponents and the data area of records 4 to 6 contain the 
velocity vector components. Again, the last (seventh) rec- 
ord of the transmission is the EOT record containing all 
binary 1 bits. The detailed format of the ephemeris trans- 
mission is given below. 



Description 


Byte 

Variable Number Type Value 


SYNCl 


1 



Byte 

88 

Sync number (later space- 
craft ID) 

INTYPE 


2 



Byte 

5 

Type of input, = 5 for 
ephemeris 

ENTRAN 


3 

to 

4 

1*2 


Running number of this rec- 
ord in transmission 

ST 


5 

to 

12 

R*8 


Start time of ephemeris 
(seconds since 9/1/57) 

NOPTS 


13 

to 

16 

1*4 


Number of data points in a 
record 

INTERVAL 

17 

to 

20 

R*4 


Time between data points 
(seconds) 

Variable 

Byte 

Number 

Type 

Value 

Description 

Record 

_1 






• 

X(l) 


21 

to 

28 

R*8 


X coordinate of first data 
point 

X(2) 

• 


29 

to 

36 

R*8 


X coordinate of second data 
point 

• 

X(N) 





R*8 


X coordinate of nth data 
point 

Record 

_2 







Y(l) 


21 

to 

28 

R*8 


Y coordinate of first data 
point 

Y(2) 


29 

to 

36 

R*8 


Y coordinate of second data 


point 


Y(N) R*8 Y coordinate of nth data 

point 
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Record 3 


Z(l) 


21 

to 

28 

R*8 

Z(2) 


29 

to 

36 

R*8 

• 

• 

■ 

Z(N) 





R*8 

Record 

_4 





X(l) 


21 

to 

28 

R*8 

X(2) 


29 

to 

36 

R*8 

9 - 

• 

• 

X(N) 





R*8 

Record 

_5 





Y(l) 


21 

to 

28 

R*8 

Y(2) 


29 

to 

36 

R*8 

• 

« 

• 

Y(N) 





R*8 

Record 

_6 





Z(l) 


21 

to 

28 

R*8 

Z(2) 


29 

to 

36 

R*8 


Z (N) R*8 


Z coordinate of first data 
point 

Z coordinate of second data 
point 


Z coordinate of nth data 
point 


Z component of velocity nth 
point 


X component of velocity of 
first point 

X component of velocity of 
second point 


X component of velocity of 
nth point 


Y component of velocity of 
first point 

Y component of velocity of 
second point 


Y component of velocity of 
nth point 


Z component of velocity of 
first point 

Z component of velocity of 
second point 
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4.6.4 EPHEMERIS REQUEST FROM AADS TO OBC(OSS) 

AADS periodically makes ephemeris requests to AADS. The 
ephemeris request is 40 bytes long and is nominally gener- 
ated by the OUTPUT process every 20 minutes. The request 
has a header with a SYNCl byte and has INTYPE = 4 for ephem- 
eris request. In addition, the message contains the re- 
quested start time for the ephemeris, number of points 
requested, and time interval between points. Nominally, 

20 points are requested at 1-minute intervals. A maximum of 
29 points can be requested. The detailed format for the 
ephemeris request is given below. 


Variable 

Byte 

Number 

Type 

Value 

Description 

SYNCl 

1 

Byte 

88 

Sync byte (later space- 
craft ID) 

INTYPE 

2 

Byte 

4 

Type of data, = 4 for 
ephemeris request 

ST 

3 to 10 

R*8 


start time in seconds 
since 9/1/57 

NOPTS 

11 to 14 

1*4 


Number of data points 
in a record 

l^JTERVAL 

15 to 18 

R*4 


Time between data 
points in seconds 

Filler 

19 to 40 

22 bytes 


Filler 


4.6.5 DATA ANNOTATION REPORT 

This report contains current time and the spacecraft atti- 
tude in quaternion and pitch, roll, and yaw forms. AADS 
downlinks this report at a high frequency (highest frequency 
once per 0.512 seconds). The r>. cord length is 40 bytes. It 
contains the SYNCl byte and has INTYPE = 3, but does not 
contain other variables from a standard header. The de- 
tailed format of the annotation report is given below. 
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SYNCl 

1 



Byte 88 

Sync number (later 
spacecraft ID) 

INTYPE 

2 



Byte 3 

Type of data, = 3 for 
annotation data 

TIME 

3 to 10 

R*8 

Time in seconds since 
9/1/57 

Q1 

11 

to 

14 

R*4 

First quaternion 

Q2 

15 

to 

18 

R*4 

Second quaternion 

Q3 

19! 

to 

22 

R*4 

Third quaternion 

Q4 

23 

to 

26 

R*4 

Fourth quaternion 

P 

27 

to 

30 

R*4 

Pitch (degrees) 

R 

31 

to 

34 

R*4 

Roll (degrees) 

y 

35 

to 

38 

R*4 

Yaw (degrees) 

Filler 

39 

to 

.40 

2 bytes 

Filler 


4i.6.6 UPDATE REPORT 


This report is generated after one or more updates and gives 
the current attitude in quaternion form and the drift rate 
biases. It gives a measure of star availability by the num- 
ber of stars used for for the update and the total elapsed 
time between the first and the last identified star. The 
identification numbers for the identified star can be used 
to verify the star identification algorithm on the ground. 
Finally, the report gives the last state covariance matrix 
and Kalman gain matrix elements. These matrices provide a 
measure of the filter performance. 


The update report consists of three records, each of which 
is 256 bytes long. The standard header for each record has 
INTYPE = 1, and INDATA = 1, 2, or 3, indicating the record 
number. The detailed update report format is given below. 



Variable 


Byte 

Number 


Type Value D escription 


Record 1 


Header 

1 to 

20 


As explained above 

Q1 

21 

to 

28 

R*8 

First quaternion 

Q2 

29 

to 

36 

R*8 

Second quaternion 

Q3 

37 

to 

44 

R*8 

Third quaternion 

Q4 

45 

to 

52 

R*8 

Fourth quaternion 

DBl 

53 

to 

60 

R*8 

Gyro drift rate bias 
in body frame, X-axis 

DB2 

61 

to 

68 

R*8 

Gyro drift rate bias 
in body frame, Y-axis 

DB3 

69 

to 

76 

R*8 

Gyro drift rate bias 
in body frame, Z-axis 

IGYCON 

77 

to 

80 

1*4 

Gyro configuration: 


= 

1/ 

Al, 

Bl, 

Cl 


2, 

Al, 

Bl, 

B2 


3, 

Al, 

A2, 

Cl 

= 

4 f 

Al, 

A2, 

B2 

= 

5, 

C2, 

Bl, 

Cl 

= 

6f 

C2, 

Bl, 

B2 

= 

7, 

C2, 

A2, 

Cl 

= 

8, 

C2, 

A2, 

B2 


STCOV 

81 to 256 

22 X R*8 

First 22 elements of 
the latest covariance 
matrix 

Record 2 

Header 

1 to 20 


As explained above 

STCOV 

21 to 132 

14 X R*8 

Last 14 elements of 
the latest covariance 
matrix 

Filler 

133 to 256 


Filler 

Record 3 

Header 

1 to 20 


As explained above 

KLGAIN 

21 to 44 

6 X R*4 

Kalman gain matrix 
after the update 
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Byts 

Variable Number Type Value Description 


DELTA 

45 

to 

48 

R*4 

Elapsed time between 
first and last iden- 
tified stars 

ELAPST 

49 

to 

52 

R*4 

Elapsed time since 
last update 

QTIME 

53 

to 

60 

R*8 

Time of state (sec- 
onds since 9/1/57) 

NS TARS 

61 

to 

64 

1*4 

Number of stars used 
for update 

IS TARS 

65 

to 

68 

1*4 

Number of stars iden- 
tified since last 
update 

KSTAR 

69 

to 

256 

Up to 
47 X 1*4 

Internal star catalog 
numbers (NSTARS x 1*4) 


NOTE ; Gyro channels 1 through 6 are Al, A2, Bl, B2, Cl, C2, 
respectively. Al, Bl, Cl is usually the primary 
channel configuration. 


4.6.7 RAW DATA REPORT 

The raw data report consists of four records. Each record 
is 256 bytes long and consists of a 20-byte standard header 
and 236-byte data portion. The value of INTYPE = 1 and 
INDATA = 5, 6, 7, or 8, respectively, for the four records. 
The report contains raw gyro and star tracker data used by 
AADS, and is generated after n state propagations or on a 
severe error in AADS. The detailed format of the raw data 


report is 
Variable 

given 

Byte 

Number 

below. 

Type 

Value 

Description 

Record 1 
Header 

1 to 
20 



Standard header with 
iNTYPE = 1 and INDATA = 5 

STIME 

21 to 
84 

8 X R*8 

4-60 

Time of last eight obser- 
vations of star camera 
data in seconds since 
9/1/57 


Byte 


Variable 

Number 


ATIME 

85 to 
88 

R*4 

IHPOS 

89 to 
152 

16 X 1*4 

IVPOS 

153 to 
216 

16 X 1*4 

I PRES 

217 to 
248 

16 X 1*2 


Filler 249 to 
256 

Record 2 

Header 1 to 
20 

SINTEN 21 to 16 X R*4 
84 


TEMP 85 to 16 X R*4 
148 


STATUS 149 to 16 X 1*4 
212 


Filler 213 to 
256 

Record 3 

Header 1 to 
20 


Value ’ Description 

Time offset for TRACKER2; 
data is offset from corre- 
sponding TRACKERl time by 
at constant amount ATIME; 
is negative if TRACKER2 
is sampled before TRACKERl 

Raw star tracker output 
for H coordinate (alter- 
nating trackers) 

Raw star tracker output 
for V coordinate (alter- 
nating trackers) 

Star presence indicator; 
=0, stars not present in 
the field of view 
» 1/ star present in the 
field of view 

Filler 


Standard header with 
INTYPE = 1 and INDATA = 6 

Star intensity (counts) ; 
last eight observations 
(alternating star 
trackers) 

Star camera temperature 
(counts) (alternating 
trackers) 

Status flag for star 
trackers (alternating 
trackers) 

Filler 


Standard header with 
INTYPE * 1, and INDATA * 7 


4-61 



Byte 


Variable 

Number 

Type 

Value Description 

GTIME 

21 to 
84 

8 X 

R*8 

Time in seconds since 
9/1/57 for last 8 obser- 
vations 

NGYRO 

85 to 
252 

7 X 
1*4 

6 X 

Most recent seven samples 
from six gyro channels 
(counts) 

Filler 

253 to 
256 



Filler 

Record 4 





Header 

1 to 
20 



Standard header with 
INTYPE = 1 and INDATA = 8 

NGYRO 

21 to 
44 

6 X 

1*4 

Raw gyro counts of eigth 
sample from six gyro 
channels 

NGYST 

45 to 
T.40 

8 X 
1*2 

6 X 

Gyro power on/off flag: 
5= 0, power off 
= 1, power on 
For last eight samples 
from each of the six 
channels 

MGYST 

141 to 
236 

8 X 
1*2 

6 X 

Gyro rate mode flag: 
=1, low rate mode 


f 2/ high rate or maneuver 
mode 

For last eight samples 
from each of the six 
channels 

Filler 237 to Filler 

256 


NOTE I Gyro channels 1 to 6 are Al, A2, Bl, B2, Cl, and 
C2. 

4.6.8 ACTIVITY LOG REPORT 

The activity log consists of a single record 256 bytes 
long. The record consists of a 20~byte header and 236-byte 
data portion. The value of INTYPE = 1 and INDATA = 9. This 
report is generated after n propagations, or on a critical 
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error. It gives a brief summary of AADS activities and 
errors encountered during processing. The detailed format 
of the activity log is given below. 

Byte 


Variable 

Number 

Type 

Value Description 

Header 

1 1 

to 

20 


Standard header with 
INTYPE = 1 and INDATA = 9 

STTIME 

21 

to 

28 

R*8 

Time and date of START 
command in the form 
YYMMDD . HHMMSS 

Spare 

29 

to 

36 

R*8 

Not currently used 

UPTRYS 

37 

to 

40 

1*4 

Total number of state up- 
dates attempted 

UPSUCC 

41 

to 

44 

1*4 

Total number of successful 
state updates 

EPHREQ 

45 

to 

48 

1*4 

Total number of spacecraft 
ephemeris requests 

GYSTATS 

49 

to 

52 

1*4 

Total number of gyro data 
saturation 

IDSTRS 

53 

to 

56 

1*4 

Total number of identified 
stars 

Filler 

57 

to 

256 


Filler bytes 


4.6.9 AADS ERROR MESSAGES 

The error message is 256 bytes long. It consists of a 
standard 20-byte header and 20-byte data portion. The value 
of INTYPE in the header is 1 and INDATA is 20 for error mes- 
sages. The first four bytes in the data portion contain the 
error number. Bytes 25 through 32 usually contain the time 
when the error was noted. However, the actual formats of 
bytes 25 through 40 depend on the specific message (see Sec- 
tion 4.5). The error message format is given below. 

Byte 

Variable Number Type Value Description 

Header 1 to 20 - - Standard header with 

INTYPE = 1 and INDATA = 20 
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Byte 

Variable Number Type Value Description 

NERROR 21 to 24 1*4 - Error number 

Data 25 to 40 - - Data associated with the 

specific error 

4,6.10 SENSOR DATA FORMATS 

In the VAX configuration, the SDS stores Landsat-D simulator 
generated sensor data in a global COMMON area. SDS does not 
queue these data but overwrites the entire buffer with new 
data each time SDS is invoked. The SENSIN process accesses 
this data area and performs initial decoding to obtain gyro/ 
star camera counts and other flags. SENSIN does not perform 
a "READ" operation, but simply accesses the data from a 
buffer. This procedure may require changing later for the 
VAX-Intel configuration or when AADS is installed onboard a 
spacecraft. The sensor data formats are included here for 
completeness even though AADS does not perform a “READ" op- 
eration to get the data from the sensors. 

Gyro data consists of six 4-byte packets. Each packet cor- 
responds to a channel; otherwise, all packets are identical 
in format. The star camera data consists of two 7-byte 
packets. Each packet corresponds to a star camera. The 
formats for gyro and star camera data are given below. 

Bit Number^ Byte Number Description 

Channel 1 

1 1 On/off switch; 

= 0, off 
= 1, on 

2 1 Mode indicator: 

= 0, low rate 
=1, high rate 


^Within bytes, bits are numbered from least significant bit 
(LSB) to most significant bit (MSB) . 
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Bit Number^ Byte Number Description 

3 to 8 1 Fill 

9 to 32 2 to 4 Counts 

Channel 2^ 

^Within bytes, bits are numbered from least significant bit 
(LSB) to most significant bit (MSB) . 

U 

"channels 2 through 6 continue in the same manner as 
Channel 1 ending at byte 24, bit 192. 

Bit Number^ Byte Number Description 

Camera 1 


1 

1 



On/off switch! 
= 0, off 
* 1, on 

2 

1 



Presence flag: 

= 1, star is present 
=0, no stars 

3 to 8 

1 



Pill 

9 to 20 

2 

to 

3 

H coordinate counts 

21 to 32 ' 

3 

to 

4 

V coordinate counts 

33 to 40 

5 



Intensity counts 

41 to 56 

6 

to 

7 

Temperature counts 

Camera 2^ 






^Within bytes, bits are numbered from LSB to MSB. 

^Camera 2 continues in the same manner as Camera 1 ending at 
byte 14, bit 112. 
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SECTION 5 - BASIC ALGORITHMS 


This section describes the Kalman filtering scheme for state 
propagation and update using 3-axis gyro data and star 
tracker data. See Reference 8 for further details. 


5.1 PROPAGATION 

5.1.1 GYRO MODELS 

The gyro output rate vector "u is related to the spacecraft 
angular velocity "w according to 

'u‘ = 'w+'b+'Tr2^ (5-1) 


where b is the drift rate bias and n-j^ is the drift rate 
noise. The vectors'll, "w, b, and are in the spacecraft 
(bodv) coordinate frame, is assumed to be a Gaussian 
white-noise process 
with constant variance 


E{^^(t)> = IT 


5-2) 


E{ir^(t) 1T^ (f)| = 


Qj^6(t-f) 



'12 

0 



(5-3) 


6(t-t') 


where E denotes the expectation and T the matrix transpose. 
The drift-rate bias is driven by a second Gaussian white- 
noise process, the gyro drift-rate ramp noise, with constant 
variance 




(5-4) 


5-1 



with 

E{-rr2(t) (t 


The two noise processes are assumed to be uncorrelated 

E{ir^(t) -fT^(t^)} = 0 (5- 

5.1.2 THE STATE EQUATION . 

The state vector of the system is given by 

^ ■ [j] 


ORIGINAL PAGE 
OF POOR QUALITY 


^ < 5 - 


•) } = Q2«(t-tM 



where q is the attitude quaternion. The quaternion and the 
bias vector satisfy the coupled differential equations 



ORIGINAL Lw 

OF POOR QUAUW, 


with 




0 

^^3 

■'^2 

w 

”'^3 

0 

'^l 

w 

CM 

a 

-Wi 

0 

w 

|_-Wi 

“'^2 

-W3 

0 


(5-11) 


Noting that the matrix function is linear and homogeneous 
in its argument, and defining the 4x3 matrix function S(q) by 


= S(q)~b 

Equation (5-9) may be rewritten as 


(5-12) 


S(q) = 


• fiCi?-t)q - 

S(q) ■ 

explicit form 


" ^4 “*33 

^2 

^3 .^4 

’^1 

"^2 

^4 

_-qi -q2 

'^3 


(5-13) 


(5-14) 


5.2 STATE PROPAGATION 

Taking the expectation of Equations (5-10) and (5-13) leads 
to equations satisfied by the predicted estimate of the state 
vector. 


I = i fi (tr-t) t 


(5-15) 


5-3 



original page 

OF POOR QUALITY. 


dt ^ 


An approximation has been made such that 

nf-'b’) ss Cu-^) (5-l‘ 

Integrating the equation shows the state estimate is propa- 
gated by 


q(t) 


= 


«(W) 


b(t) = b(tp) 


where W = u - b. If the direction of "w is assumed constant 
over the interval (t, tQ) or if the rotation vector defined 
by 




') dt' 


is small, then using average value 


t A 


W dt' 


"0 

t - t, 
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we get 


ORJGir^AL 

DE POOR QUAUW 


t(t) 


1/2 fi(^) (t-t.)^ 

° t(to) 


(5-22) 


or 


t(t) 


= |cos I 


(t-to) 14 x 4 


sin I (t-tQ)\ 

+ ^ -)S2(^ t(to) 


(5-23) 


where W = I'^l and is the identify matrix of order 4x4. 

Letting t = t^, t^ = and t^ - = At leads to 


/ sin ^ AT \ A 

t(t„) ’\ccs^ At ^ 


(5-24) 


= ‘^<"n-l^ 


(5-25) 


Taking first-order approximation in the trigonometric func- 
tions gives 


t(t„) ^ ( 


i4x4 ^ r “<«> 




"bCt ) ="&(t ,) 

n n-i 


(5-26) 

(5-27) 


Quaternion should be renormalized after propagation using 
approximation Equation (5-26) . 
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ORIGINAL PAGS iH 
OF POOR QUALITY. 


5.3 STATE -ERROR EQUATIONS 

The State-error vector is defined by 

AX' = X - 2 (5- 



where 


’3x4 


OSISfWiiL Pk 83 m 
OF POOF? QUflUTl! 

is a null (zero) matrix of order 3x4. 




1/2 S!(w) (t-tp) 


w 


w 


= cos ^(t-to) 14^4 


(5-34) 


+ 2 J2(^) 


w 


<0l2(trto) = 


“ I / <l>ii(t^t' ) S (q{f )) df 


(5-35) 


^i(t»to) = 


■’/ 


4)j^j^(t,t' ) S(t(f )) 


(5-36) 


X [f 2 (f ,tQ) + lTi(t' )] dt’ 


^2 


•/ 


3^2 (f) dt' 


(5-37) 


5.4 COVARIANCE PROPAGATION 

The covariance matrix is defined by 


P(t) = E{AX(t) (t) } 


(5-38) 
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ORIGINAL PAGE m 
OF POOR QUALITY 


It follows from the state-error equations that the covari- 
ance matrix is propagated by 


P(tn> 


'll l-i> 

I 


12 


I 


P(t i) 
n-1' 


°3x4 1 ^3x3, 


'll 

Q 


i Qi2 

L 


21 i ^22y 


/•“ ; 

CM 

•e- 

V3X4 i 

^ 3 x 3 / 


(5-39) 


where 


(t>ii - 

*^12 "" ‘^12^^n'^n-l^ 


(5-40) 

(5-41) 


Qll = E 


tn tn 

= E{£^f^| = i y J S(t(f)) 


'n-1 


n-1 


(5-42) 


'12 


X E|(f2(t',tj^_^) + ■n*i(t')) (f2(t"^tj^_l) 

+ Tfl(f •))'^} s’’(t(t")) 4>n(t^,t") dt‘ dt" 

^n ^'n 

= E{fi£^}=-| / j 4,^^(t„,f) S(t(f ) 

^n-1 ^n-1 

X E|(f2(t'Et^_3,) + \{tn) ~n^ (t")} dt' df 


(5-43) 
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PMiI .Si 

OF POOR QUAU'at 

n 

E|Tr^{f ) ’ ,t„ ,) 

1 

+ ir3^(t")’’)} s'^(q(t")) <|)ii 

°22 " ®{^2 ^ 2 } ^ 

X E{tr2(t’) 1T: 

The covariance matrix for the seven-dimensional state vector 
is singular. This follows from the constraint on the 
quaternion norm, that is 

q'^q = 1 (5-46) 

The singularity is difficult to maintain numerically due to 
the accumulation of round-off error. In fact, P(t^) may 
even develop a negative eigenvalue. The simplest way to 
maintain the singularity is to represent P(tp) by a matrix 
of smaller dimension. 

A 6x6 representation of the covariance matrix is derived 
below. 

It can be shown that 

<|>^3^{t,tQ) S(t(tQ)) * S(^(t)) ?3^^(t,tQ) (5-47) 


I e- 


(5-44) 


(tj^,t") dt' dt" 


/" r 

^n-l ^n-1 


!?(t" ) ^ dt* dt' ' 


(5-45) 


'21 


= E{f2 fl} = - I / / 


n-1 
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ORIGINAL PAGE IS 

and OP POOR QUALITY 

4»il (t,to) = S(t(t)) S'^(§(tQ) ) 

+ t(t) §'^(tQ) 

where 




c|)^ 3 ^(t,t ) = e 




=e 


is the 3x3 attitude rotation matrix and 




0 

-w. 


w. 


-w 


w. 


L y 


0 

-w. 


w. 


Substituting into Equations (5-41), (5-42), (5-43), and 
(5-44) we get 




= S($(t„)) 3,, s’’(t(t„)) 




n 


= S(q(t^)) 


(5-54) 


0R»©1^5A1- 

OF POOR QtiAUTY. 


Q21 “ ^21 s"^(q(t.)) 


n 


^22 ' ^22 


where 


<Dl2(t 


t ) A 

n'^n-1^ 2 J 


4>ii(tn,f ) df 


’n-l 




11 


/.tn 


n-l n-l 


12 




■^n-1 


+ Tfi(t') ) n^(f ’) } df dt' ' 


•21 


■ ■ ^ /" /” ■(" 


2(f ) (f2(f \tn-i) 


"n-l 


+ % (f •))'^ 


Kl<'=n' 


f ') df dt 


(5-55) 


(5-56) 


(5-57) 


) 

(5-58) 


(5-59) 
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ORlGmAL 
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/ *'n /*^n 

/ " eIiTjU') (t")} dt' at" (5-60) 


•=n-l '^n-l 


Substituting Equations (5-47) and (5-48) into Equa- 
tion (5-39) , the covariance matrix propagation can be v/ritten 


P(tn) 








5 (tn) q (Vi) I 0,^3 




+ ^(t(t^)) SW (t(t^)) 


I ° 3 x 3 


t(V ^<Vi> 

1 

1 

1 

1 

° 4 x 3 

° 3 x 4 

1 

1 

1 

° 3 x 3 
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,^(q(t)) = 


S(t(t)) 

1 

1 

1 

° 4 x 3 


~r 

1 

1 

^ 3 x 3 


^■(t.,t^_J = — — ! — — 


(5-62) 


(5-63) 




. _ - fwv n. ■ V-* 

OF. POOR Ql#A^i5 


The second term of the right member of Equation (5-65) van- 
ishes since 


q t^P = 0 


(5-65) 


because of the normalization condition (Equa- 
tion (5-46) ) on q. 

Thus, the 6x6 covariance matrix can be defined by 


1?(t) =->^'^(q(t)) P(t) ,^(t(t)) 


(5-66) 


and it is propagated by 


This covariance matrix corresponds to the state-error dif- 
ferential equations 


aT = ??(^ ” •! ^ ■ T^l 


(5-68) 
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The following gives further derivation of ^ and ^ from Equa- 
tions (5-49), (5-56), (5-57), (5-58), (5-59), and (5-60) 
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5 . 5 UPDATE 

The measurement vector at time tj^ , is related to the 
state vector 



(5-81) 


(5-82) 


where r the measurement noise^ is a discrete Gaussian 
- k 

white-noise process 

= 0 (5-83) 


The minimum-variance estimate of immediately following 
the measurement is given by 

■*' *^k[-k ■ (5-85) 
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where the Kalman gain matrix is given by 


''k = *’k<-> «k [«k'’k<-> «k 


+ "k] ^ 


(5-86) 


and the measurement partial matrix is given by 


3h(X) 
" “33T 


Xk(-) 


(5-87) 


the covariance matrix immediately following the measurement 
is given by 


' '^7x7 - Vk> 


(5-88) 


Notice that ^]^(”) and P|^(") denote the predicted values of 
the state vector and stats covariance matrix at time tj^ , and 
£j^( + ) and Pj^(+) denote the same quantities immediately 
following a measurement at time tj^. 


The update algorithm may also be mechanized using the 6x6 
covariance matrix V{t), Define the nx6 matrix the 6xn 
matrix and 6x1 vector 
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Then it can be shown that 


= <^6x6 - Vk> ^k<-> 








n is the dimension of the measurement vector. The quater- 
nion part of the state vector should be renormalized after 
the update, that is 


^ ^k<*> 

■3k ' H— T 
qk<*) 


tu(-) + Aq, 


For each star observed by the star tracker, we define two 
model measurements 


^ (h\ /V^s\ 
'Ihi/ 'I V^s/ 


(5-9 


where X , Y , and Z_ are components of the star unit vector 

9 0 S 

represented in star tracker frame. 
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Vg is related to the star unit vector in spacecraft body 
frame and inertial frame by 

"Vg = M iTg = M A(q) (5-99) 



where M is the spacecraft body to star tracker rotation ma- 
trix (misalignment of the star tracker included in this rota- 
tion) and A(q) is the attitude matrix given by 


A{q) 
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2(qiq3 - q2q4> 
2(q2q3 + qiq4) 

-qf - ql + q^ + qj 


(5-100) 


The measurement partial matrix is given by 
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It can be shown that 



(5-101) 
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2??'(A^) (5-105) 


Thus, we have the reduced measurement partial matrix given by 




9h 
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'2x3 


(5-106) 


In general, Z, h, and be 2m-component vectors, 

2mx6 matrix, and it 6x2m matrix, where m is the number of 
stars observed at a certain time.. 

The matrix Equations (5-93), (5-94), and (5-95) can be de- 
composed and manipulated to give rise to a set of recursive 
formulae. Components of the measurement vector can be proc- 
essed through the recursive formula one at a time. The final 
result should be the same as that obtained using full matrix 
equations. The recursive formulae are given by 

'4„ - - h„(2o> - ^ t„-i] (5-107) 

* ^n-1 ^n-1 ^^(^o)] ^ <5-108) 


^ = [ 1 ^ . - H (^^)I ? , 

n 6x6 n n '—0 •' n-1 


(5-109) 


^h' ^n' ^n matrix) are nth row of Z, h, and H, respec 

tively. is the initial estimate of the state vector be- 

fore any component of the measurement vector is processed. 

and a 5? , are the corrections to the 6-component state 

-fn — n-i 

vector after processing n components and (n-1) components of 
the measurement vector, respectively. and 3ce the 

corresponding 6x6 state covariance matrices. is the 6x1 

Kalman gain matrix after processing n components of the meas- 
urement vector. 
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APPENDIX A - 'T’iminG AND MEMORY ESTIMATES 


These estimates were made during the previous design process 
(Task 92300) . These estimates were given in the document 
entitled, Microprocessor-Based Autonomous Attitude Determi - 
nation System Design (CSC/TM-81/6085) (Reference 3) and are 
reproduced here for convenience. 


A. 1 TIMING AND MEMORY STUDIES 

The ability of the design to meet computational requirements 
was shown earlier. The ability to meet the execution time 
and memory requirements is described in this section. 


Implementation of AADS on the target microprocessor, the 
Intel 8086/8087 microcomputer, is constrained by the amount 
of Intel computer memory available to AADS, the timing re- 
quirements for AADS execution, and the accuracy requirements 
for attitude determination. This section describes the 
analysis performed to demonstrate the feasibility of imple- 
menting AADS on the Intel computer. 

Estimates of AADs memory and timing requirements were deter- 
mined from published data on memory and timing needs of 
similar software systems designed for the NASA Standard Sys- 
tems Computer (NSSC-1) and the manufacturer's specifications 
for the Intel hardware capabilities. A study was conducted 
to identify the AADs parameters that are critically sensi- 
tive to computer truncation errors and must be represented 
in double-precision format to prevent degradation of atti- 
tude determination accuracy. Results of the study indicated 
that the number of these parameters did not significantly 
alter the AADS memory and timing estimates. 


Sections A. 1.1 and A. 1.2 document the AADS computer memory 
and timing studies, respectively. Section A. 1.3 presents 
the analysis and results of the floating point precision 
study. 
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A. 1.1 AADS MEMORY REQUIREMENTS STUDY 

In this section, conservative estimates are developed for 
the memory requirements of AADS. It is shown that AADS can 
reside on the Intel 8086/8087 without violating the 
250K-bvte total memory address limitations of the Intel. 

The AADS memory estimates are based on memory sizings per- 
formed for similar software implemented on the NSSC-1 com- 
puter. The increased memory needed to accommodate the large 
AADS star catalog and data output buffer was taken into ac- 
count. The AADS design specifications provide for a star 
catalog that contains all the SKYMAP catalog stars down to a 
stellar magnitude of 6.4, approximately 8500 stars, and a 
data output buffer that stores samples of raw and reduced 
data as well as spacecraft attitude and critical performance 
parameters. To extrapolate the memory requirements evalu- 
ated for an onboard attitude determination system installed 
on the NSSC-1 computer to the Intel microprocessor, each 
NSSC-1 18-bit word was associated conservatively with two 
Intel 16-bit words. The estimated memory requirements of 
the AADS subsystem are presented in Table A-1. 

AADS memory requirements are compatible with the Intel com- 
puter operating environment. Although the Intel can handle 
up to 1 megabyte of memory, a design requirement limits the 
size of AADS to 256K bytes. The Intel operating system and 
mathematical package are assumed to use 16K bytes, leaving 
240K bytes for AADS code and data storage. All data and 
code must be stored internally in memory, since the Intel 
operating environment will not include peripherals. Prom 
Table A-1, the memory estimates for each process show that 
AADS will need a maximum memory size of 175K bytes. This 
estimate is well within the 240K bytes of memory allocated 
to AADS for the Intel. 



U 




Table A-1. Memory Requirements on the Intel 8086/8087 

Memory Required (K Bytes) 

Process Program Data Total 


Input Data Processing 1 
Gyro Data Processing 2 
Gyro Propagation 3 



Star Data Processing 8 

and Star .Identifica- 
tion 

Attitude Update 3 

Output Data Processing 1 


142® 150 

1 4 

10 11 


18 157 175 


^Large catalog size because some redundant information is 
stored to save execution time. 



A. 1.2 AADS TIMING REQUIREMENTS STUDY 

The goal of the timing study was to estimate the execution 
times of AADs processes and to perform a throughput analysis 
demonstrating that the Intel 8086/8087 microcomputer can 
microcomputer can execute a worst-case AADS operational 
scenario within the specified processing cycle time. AADS 
process execution times were estimated from the reference 
times provided by studies of the execution of an onboard 
attitude determination system on the NSSC-1 computer. 

To compare the execution times of the same process on the 
Intel and the NSSC-1 computers, the relative speeds of the 
two computers were estimated. The first step in this anal- 
ysis was to determine the instruction timings of the two 
computers. The instruction timings are presented in' 

Table A-2. The cycle times of the NSSC-1 and the 
Intel 8086/8087 computer are 1 microsecond (vis) and 
0.5 ys, respectively. The Intel performs a LOAD or STORE 
operation in 4 ys, and the NSSC-1 requires 9.5 ys to 
execute the corresponding operations. The faster perform- 
ance of the Intel is because of its cache memory , which in- 
cludes six prefetch registers. Analysis of the COMPARE 
operation indicates that it should require at least twice 
the time of the respective LOAD opeations, namely 19 ys 
for the NSSC-1 and 8 ys for the Intel. 

The Intel floating point instruction times were obtained 
from the Intel 8086 family user's manual. The corresponding 
NSSC-1 instruction times represent the times estimated for 
the NSSC-1 mathematics package to emulate the floating point 
instructions. Table A-2 also provides ratios of the execu- 
tion times for each timing instruction on the Intel and 
NSSC-I computers. One estimate shows that AADS code will 
consist of 70 percent load-and-compare (L&C) instructions, 

22 percent single-precision (SP) arithmetic instructions, 
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Table A-2, Comparison of Instruction Timings on the NSSC-1 
and Intel 8086/8087 Computers 


Instruction 

NSSC-1 (MS) 

Intel (MS) 

Ratio of 
Intel to 
NSSC-1 

Load -and -Compare 
Load 

9.5 

4 

0.42 

Compare 

19 

8 

0.42 

SP Arithmetic"^ 

SP Add 

18 

17 

0.94 

SP Subtrack 

18 

17 

0.94 

SP Multiply 

53 

19 

0.36 

SP Divide 

85 

39 

0.46 

DP Arithmetic'^ 

DP Add 

63 

22 

0.35 

DP Subtract ' 

83 

22 

0. 26 

DP Multiply 

233 

27 

0.12 

DP Divide 

2500 

50 

0.02 


^SP = Single Precision 
2 

DP = Double Precision 
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and 8 percent double-precision (DP) arithmetic instruc- 
tions. The frequency of use of the basic types of arith- 
metic instructions in representative applications software 
is shown in Table A-3. Estimates for the distribution of 
the different types of instructions in AADS code were used 
in compute a weighted mean ratio of the instruction execu- 
tion times of the Intel and NSSC-1 computers. From the 
estimates provided in Table A-3, weighted means were derived 
for the Intel/NSSC-1 ratios of singleand double-precision 
arithmetic instruction times. These ratios, in conjunction 
with the distributions and timing ratios of the remaining 
instruction types, were then applied to computing the final 
weighted mean execution time ratio, using the formula: 

Intel/NSSC-1 Execution Time Ratio = 70% L&C + 22% SP + 8% DP 

= 0.7 (0.42) + 0.22 (0.85) 
+ 0.08 (0.28) 

= 0.5 

This result predicts a twofold improvement in the perform- 
ance of the Intel microprocessor over the NSSC-1 computer. 
Approximate execution times on the Intel computer for AADS 
processes were calculated by multiplying the times deter- 
mined on the NSSC-1 for executing comparable processes by 
the Intel/NSCC-1 timing ratio. 

Table A-4 presents the processing times in milliseconds (ms) 
predicted for AADS processes. Because I/O times could not 
be translated directly from the NSSC-1 to the Intel, 

Table 1-5 does not included estimates for the AADS INPUT and 
OUTPUT processes. Very rough estimates for Intel I/O times 
were obtained by assuming that the time to input/output a 
16-bit word between memory and the Intel 64K buffer and the 
time (0.5 ys) to execute the buffer/transmission line in- 
terface. Based on an I/O execution rate of 3 ys//wotd, 
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Table A-3. Frequency of Use of Arithmetic Instructions 
in Applications Software Cycle 


Operator 

Add 

Subtract. 

Multiply 

Divide 


Percentage 

57 

26 

13 

4 
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Table A-4, Timing Estimates for AADS Processes Implemented 
on the Intel 8086/8087 



Gyro Data Processing 20 
Gyro Propagation 35 
Star Data Processing 25 
Star Identification 100 
Attitude Update 90 


Total 260 ms 



the time to output 5000 words, the maximum number stored in 
the lOK output data buffer, would be 15 ms. Input process- 
ing will required less than 1 ms because of the relatively 
small amount of AADS input data. 
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APPENDIX B - QUESTIONS AND ANSWERS 


This section contains questions raised by the design team. 
Each question is numbered to indicate the area of the design 
to which it pertains. The numbering scheme is as follows: 


Code Area of Design Page 


EX 

Executive process 

B-2 

10 

INPUT, OUTPUT, SENSIN processes 

B-25 

AT 

Attitude processes 

B-40 


Each question is dated and indicates the person who asked 
the question and the person who answered the question. When 
an answer to a question is available, it follows the ques- 
tion in the text. Q: indicates the beginning of a ques- 
tion; A: indi^;ates the beginning of an answer. 

The information obtained through these questions has been 
incorporated in the body of the document; however, the ques- 
tions and answers are reproduced here to document the evolu- 
tion of the AADS design. In some cases, the answers are 
incomplete or inaccurate becaue sufficient information was 
not available at the time. Brief notes are added after the 
answers to indicate this problem. 

Sections 1 through 5 of this document should be consulted to 
resolve ambiguities or discrepancies. 




Number EXOOl 

Originator K. Saralkar Answered by S. Sanders 

Date 6/23/81 Date 7/3/81 

Q: What sort of Software Clock will be us#d by AADS? Three 

possible clocks are described below. 

1. The current time will be taken from the system 
clock. It will be in the form of year, month, day, and 
milliseconds of the day and will be very easy to implement 
for the prototype system. This will result in a single 
source of time for the OSS, SDS and AADS. The orbit program 
(AODS) uses this type of clock, but AODS is designed for the 
LSI-11. The operating system and the software clock fea- 
tures for the LSI-11 are similar to those for the PDP-11. 
AADS will have to change the logic based on the operating 
system clock if a microprocessor other than the LSI-11 is 
used. 

2. A hardware counter with a full day capacity which 
is available to all onboard computers. GSS will uplink the 
start time. AADS will keep a counter for year, month, and 
day that will be set from the start time. The hardware 
counter will be set to the milliseconds from the start 
time. Any delay (offset time) in resetting the clock after 
the RESET command can be automatically added to the counter. 

3. The hardware counter may cycle over a shorter time 
period; then AADS will keep cumulative time in its memory. 
The counter may generate an interrupt every N milliseconds; 
AADS will update the time register and reset the counter 
after an interrupt. AADS will have to compensate for any 
delay in or overhead required to perform these actions. 

(See question 10003.) 
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Number EXOOl (Cont'd) 


A: The time will be obtained from the operating system in 

the form of year/ month, day, and milliseconds of the day. 
Timers and system event flags based on timers will be avail- 
able. This arrangement is based on the following proposed 
scenario. 

The microprocessor will be provided with interrupts at reg- 
ular time intervals, approximately every 10 milliseconds. 
These interrupts will be generated by the spacecraft clock 
for the actual onboard system. During simulation testing, 
these interrupts will be provided by a combination hardware 
and software configuration on the VAX-11 computer. The 
operating system in the microprocessor will use these inter- 
rupts to maintain the time. A subroutine may be needed for 
AADS to set the initial time in the operating system. This 
time would be obtained from the SET CLOCK command. The 
granularity of the time is not expected to have an adverse 
effect on AADS. 

NOTE ; 1. AADS will use the system clock on the VAX. The 
SET CLOCK command will not be used. These re- 
quirements are TBD by GSFC on the Intel version 
(8/24/81) . 

2. Test runs on the VAX-11/780 computer indicate that 
the 10-millisecond granularity and scheduling 
variations result in time tag errors for both gyro 
and star tracker data. These time tag errors pro- 
duce an error of several arc seconds in the com- 
puted attitude (4/2/82). 
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Number EXQ02 

Originator G. Klitsch Answered by F. Snow and 

K. Tasaki 

Date 6/23/81 Date 7/3/81 

Q: Will attitude results be output at regular intervals, at 

the request of the OSS, or both? 

If requested by the OSS, will the request be for the most 
recent computed or propagated attitude, or will the request 
be for a previous attitude with a specified time? 

Recommendation ; If attitude results are requested by the 
OSS, the requests should be for the most recent attitude. 
This would eliminate the need to store previous attitudes in 
some wraparound queue, which would, in turn, reduce memory 
requirements and simplify logic. The need to flag previous 
attitudes as questionable when a RESET CLOCK command is 
processed or when a new state attitude is uplinked would 
also be eliminated. Moreover, it would be undesirable to 
have to interpolate between attitudes of enclosing times. 


A: The most recent computed or propagated attitude will be 

output after every nth propagation, where n is an adjustable 
integer parameter. This output will start when propagation 
starts and will continue until gyro processing is sus- 
pended. Initially, n will be set to one. 


B-4 


Number EX003 

Otiginator G. Klitsch Answered by F. Snow 

Date 6/23/81 Date 7/3/81 

Q: Reports containing activity log entries, raw sensor 

data, global COMMON variables, and so on will be produced 
for downlink upon command. Will there be a requirement to 
output periodic reports over a specified time period? This 
would require commands specifying a start and end time and a 
STOP PERIODIC REPORTS command if a very large end time was 
specified. 

Recommendation ; Although this capability would increase the 
debugging capabilities in AADS, it would also complicate the 
scheduling logic and increase the size of the executive. 

This capability may be desirable during critical events, 
such as a maneuver. Tradeoffs in memory and time will have 
to be studied further before a recommendation can be made. 

A; There is no requirement to output periodic reports over 
a specified time interval. The activity log will be down- 
linked by command or upon a critical error. Update perform- 
ance parameters and the raw sensor data reports will also be 
downlinked upon a critical error. In addition, propagation 
and update performance parameters will be downlinked after 
every update, and the log of sample, raw sensor data will be 
downlinked on command. 

The raw sensor data report will contain 14 entries with a 
period of approximately 0.5 minute. Thus, the log will 
contain samples covering approximately 7 minutes. The log 
will probably be wraparound, and the exact time between 
samples will probably be variable. See Table B-1. 
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FREQUENCY' 


TYPE OF 
OUTPUT 


Q < (/> Ui 

>1 Sg >H 

®o p2 ®< 

uiu Es uio 

>uj OCX >0, 

UIW UU UlX 


PROPAGATED ATTITUDE 


PROPAGATION AND UPDATE 
PERFORMANCE PARAMETERS 


SAMPLE RAW SENSOR DATA LOG 


ACTIVITY LOG 


■THERE IS NO OUTPUT BY TIME. 


There is no output by time. 


OTE ; See Section 4.6 on message formats for additional in 
formation. Propagated attitude, activity log and 
sensor data reports are downlinked after n propaga- 
tions where the factor n is separately selected for 
each report. The update performance report is down- 
linked after m state updates. In addition, the 
activity log and the raw sensor data report are down 
linked in the event of an error (4/2/82). 











Number EX004 


Originator G. Klitsch Answered by 

Date 6/23/81 Date 

Q: A wraparound activity log will be maintained to record 

the activities of AADS. A level-of-diagnostics parameter in 
a global COMMON area may be desirable to select the amount 
of information that should go into this activity log. This 
parameter could have the following values and meanings: 

1. Everything. This includes routine scheduling, 
commands received and responses to them, and severe 
and minor errors. 

2. Everything except routine scheduling. 

3. Severe and minor errors only. 

4. Severe errors only. 

Recommendation ; This parameter could be implemented easily 
and would provide greater flexibility in the recording of 
AADS activities. 

NOTE : Activity log format is fixed and given in Section 4 

(4/2/82) . 



Number EX005 


Originator G. Klitsch Answered by F. Snow 

Date 7/6/81 Date 7/10/81 

Q: Is AADS required to continue gyro data processing and 

propagation during a maneuver, or should AADS suspend proc- 
essing and wait for a new state attitude uplink following 
the maneuver? 

If AADS is required to continue processing, should the fre- 
quency of gyro data processing and/or propagation be in- 
creased, or should the error bounds on the gyro data be 
increased, or both? If the frequency of processing is in- 
creased, would this increase vary according to the maneuver, 
or would it remain constant? Will the same attitude ac- 
curacy requirements be in effect? 


A: AADS is required to continue gyro data processing and 

propagation during a maneuver. The frequency will be in- 
creased? and the error bounds will remain unchanged. The 
gyro data processing and propagation frequency should be 
Increased since no star tracking will be performed during a 
maneuver. The increased frequency sfiould be the same for 
any maneuver. The attitude accuracy requirements also will 
remain the same. Star tracking will be resumed to obtain an 
attitude update following the maneuver. In addition, the 
gyro data processing and propagation frequency will be reset 
to the original value. 


Number EX006 

Originator G. Klitsch Answered by F. Snow 

Date 7/6/81 Date 7/10/81 

Q: If star tracking is delayed because of a maneuver or the 

occultation of both star cameras, should the time limit for 
the next update be extended by an equivalent amount of time? 


A: The time limit for an update should not be increased 

eiven if st.-'r tracking is delayed because of a maneuver or 
the occultation of both star cameras. A critical error mes- 
sage is downlinked if this time limit is exceeded. Ground 
support personnel should take into account any maneuver of 
the occultation of both star cameras in interpreting the 
error message. 
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Number EX007 


Originator G. Klitsch Answered by S. Sanders 

Date 7/8/81 Date 7/17/81 

Q: How accurate must the scheduling be? Must the schedul- 

ing be accurate to the centisecond or millisecond level? 
According to recent discussions, the proposed target com- 
puter will be getting timer interrupts approximately every 
10 milliseconds, a condition making millisecond accuracy 
impossible. The choice of accuracy would also affect how 
the system time would be obtained on the VAX-11 computer. 

The $GETTIM system directive returns the current system time 
in a 64-bit guadword. This system time is in 100-nanosecond 
units measured from the system base time. While this would 
achieve millisecond accuracy, manipulating a 64-bit guadword 
could be difficult. The subroutines IDATE and SECNDS return 
the date and seconds of the day. The seconds of the day are 
returned in a single-precision real variable accurate to 
.01 second. This would achieve centisecond accuracy. 

The $SETIMR system directive, used to set the system timer, 
reguires input in the form of a 64-bit guadword. However, 
for variable time slicing, delta times can be specified 
instead of absolute times. This allows the guadword to be 
broken into two longwords with the first longword egual to 
-1 and the delta time specified in the second longword as a 
negative number of 100-nanosecond units. Conversion to 
these units would be simple and would allow for a delta time 
of over 7 minutes, much larger than any expected time slice. 

Recommendation : Accuracy to centiseconds is recommended. 

NOTE ; The scheduling accuracy is at most 10 milliseconds. 
Procedures for increasing accuracy are TBD by GSFC 
(8/24/81). 


A: The scheduling can be accurate to the centisecond level 

only. Although the $SETIMR requires time input in 
100-nanosecond units, it can measure time only in 
10-millisecond units. Thus, accuracy to the millisecond 
level is impossible. 



Number EX008 


Originator G. Klitsch Answered by P. Snow 

Date 7/16/81 Date 7/17/81 

Q: AADS will generate requests for occultation and ephem- 

eris data, which are then produced by the OSS. Since maneu- 
vers are planned by ground support personnel, the only 
maneuver schedules available to the OSS are those that the 
OSS receives from the ground. Should AADS generate requests 
for maneuver schedules, or should the lack of current ma- 
neuver schedules be construed to indicate that no future 
maneuvers have been planned? 


A; AADS will not maintain a maneuver schedule unless the 
need for one is demonstrated at a later date. AADS will be 
able to detect a maneuver through a gyro gain change or a 
gyro rate change. When AADS detects a maneuver, the results 
of any current star camera processing will be purged, and 
the frequency of gyro and/or propagation processing will be 
increased. Following a maneuver, the frequency of process- 
ing will return to normal, and star camera processing will 
be restarted. 
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Number EX0Q9 

Originator G. Klitsch Answered by F. Snow 

Date 7/16/81 Date 7/18/81 

Q: What is the expected time interval between ephemeris 

elements, and how much ephemeris data (how many elements) 
will be provided at a time? 

A; A request for ephemeris data from AADS will include the 
timespan and the interval between ephemeris elements. This 
time interval between elements could be, for example, on the 
order of 1, 2, or 5 minutes. There will be an upper limit 
on the total number of ephemeris elements, probably 20. An 
ephemeris element will consist of the velocity vector and 
associated time, since this is all that is rjequired by 
AADS. AADS will use a small interpolator to interpolate 
between elements as needed. 

NOTE : AADS will request ephemeris at 1 minute intervals, and 

will use a six-point interpolator. Nominally, AADS 
will request 20 points at 1 minute intervals. The 
maximum number of points per request is 29 (4/2/82). 
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Number EXOlO 

Originator G. Klitsch Answered by F. Snow 

Date 7/16/81 Date 7/17/81 

Q: Will the occultation data provided to AADS take into 

account any planned maneuvers and the predicted attitude 
following a maneuver? If not, will updated occultation data 
be provided automatically following a maneuver, or should 
AADS generate a request? If AADS must generate a request, 
should it output the propagated attitude following the 
maneuver before generating the request? 

A:i A request, for occultation data from AADS will include a 
requested timespan and the current propagated attitude* 
Following a maneuver, a request for occultation data will be 
made since any previous occultation data may be invalid. 

NOTE; AADS will compute occultation information (8/24/81) . 
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Number EXOll 


Originator G. Klitsch Answered by S. Sanders 

Date 7/16/81 Date 7/31/81 

Q? On the Intel microprocessor, will the memory used by a 
process or by an executable image include the sizes of the 
global COMMON areas it accesses and/or the general subrou- 
tines (Math Pac) that it uses? This question is related to 
how executable images are created on the Intel and should be 
referred to Steve Sanders of Systex. 

If the sizes of global COMMON areas and/or the general sub- 
routines used by a process are included in the amount of 
memory used by a process, global COMMON areas and/or general 
subroutines could becom.e a significant part of the 64 kilo- 
byte limit per process. Furthermore, would the sizes of 
global COMMON areas and/or general subroutines be counted 
more than once in the 256-kilobyte overall limit? 

A; Steve Sanders (from Systex) feels that the actual ad- 
dressing limit for the Intel 8086 may be 128 kilobytes; the 
mathematical subroutines package can be shared by all the 
processes; and the global COMMON areas and the mathematical 
subroutine package will be counted in the address space al- 
located for each process. He also feels that there may be 
an address granularity of the order of 4K bytes. He will 
review the FORTRAN compiler when it becomes available to 
verify the aforementioned answers. 

NOTE ; Steve Sanders feels that 64 kilobytes each for 
instruction, data, and global COMMON is allowed 
(8/24/81). 
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Number EX012 

Originator K. Saralkar Answered by S. Sanders 

Date 8/17/81 Date 8/21/81 

Q: The high density RAM chips used for the Intel computer 

may exhibit random bit failures. 

1. What is the rate of memory failure? 

2. it possible to use error checking and correcting 
memories? | 

3. Caiin we use electrically erasable programmable 
memories (eWoms) for certain critical portions of the pro- 
gram to guard against such memory failures? 

4. Is there a monitor program that can perform check- 
sums to monitor the integrity of the memory? 


A: 

1. A 1-bit-per-month failure rate has been quoted for 
some 16-kilobyte RAM chips. 

2. Error checking and/or correcting memories are too 
expensive and will not be used for the AADS target computer. 

3 The EPROMS are currently available as 2 kilobytes 
per chip. This low density presents a packaging problem for 
the current hardware design. 

4. No such monitor program is planned at present. The 
RAM failure rates are small enough to exclude the use of the 
monitor programs. 
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Number EX013 


Originator K, Saralkar Answered by K. Tasaki 

Date 8/18/81 Date 8/21/81 

Q: 

1. Is there any requirement to uplink AADS or the star 
catalog during the mission? If so, define the mechanism for 
the uplink. 

2. What is the limit for the dimmest star in the star 
catalog? Is this number variable during the mission? 

A: 

1. The star catalog will be loaded along with AADS 
before execution of the prototype program and will not’ be 
changed during execution. The mission requirement is TBD 
(but the star catalog will not be changed provided that the 
entire star catalog of the 8500 stars can be stored onboard) 

2. 6.4 is the nominal limit for the dimmest stars. 

The actual limit is TBD by GSFC depending on the star cata- 
log size considerations. The magnitude limits are not vari- 
able. 

NOTE : The AADS star catalog contains 8666 stars in the mag- 

nitude range 2.0 to 6.5. The Landsat simulator uses 
stars with magnitudes down to 5.25 (4/2/82). 



Number EX014 


Originator K. Saralkar Answered by K, Tasaki 

Date 8/18/81 Date 8/21/81 

Q; Can we use a software clock (with a scaled time) to 
speed up or slow down the testing? 

AADS and the AADS simulator will use a synchronized software 
clock for this purpose. The following advantages can be 
seen. 

1. Use of the clock will speed up real-time testing. 
For example, a 24-hour simulation can be performed in 1 or 
2 hours. 

2. High priority jobs or block times that could affect 
other users will not be required. 

3. Conversely, high priority jobs by other users will 
not affect AADS system testing. 

4. Costly manual supervision during testing will be 
reduced. 

5. The program could be slowed down or stopped during 
a debug run to allow the use of the Dynamic Debugging Tech- 
nique (DDT) . A real-time clock will result in a loss of 
synchronization during stops for diagnostics. 

A: AADS will get high priority on the VAX computer for 

testing purposes. GSFC does not want to use the scaled time 
since the AADS si=‘“'.ulator will also have to be changed. 
However, this requirement is TBD by GSFC (8/24/81) . 

NOTE : Speeding up testing by compressing out dead times has 

more advantages (8/24/81). 
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Number EX015 


Originator Y. Frenkel/K. Saralkar Answered by 
Date 9/01/81 Date 

Q: AADS code and data will be stored in RAM in the current 

flight system configuration. In this case, AADS should be 
supported during flight by RAM, checksum and benchmark test 
routines. These routines will be invoked by commands from 
the ground, or automatically for a predetermined condition 
such as a restart of AADS, 

1. RAM test routine will check all RAM memory sequen- 
tially, Each location will be saved in a temporary area. 

The RAM test routine will (a) Set all bits (1) , (b) reset 
all bits (0) , (c) shift left 1 bit, and (d) shift right 

1 bit. Finally, the original contents will be restored. 

The address of each location that produces an error will be 
transmitted to ground, (Note: find size/time for the test 

routine,) 

2. Checksum routine will add all 1 bits in the entire/ 
ROM memory. The count will be compared to the previously 
known count. An error message will be transmitted to the 
ground if the counts do not match, 

3. A complete batch of data (gyro and star tracker 
data/ephemer is , etc,) will be stored in memory along with 
the previously calculated or known answers for attitude and 
identified stars, 

a. Batch Benchmark Test : The benchmark data will 

be used in a batch run, i,e,, all processes will run on 
completion of previously scheduled processes, and not wait 
for timer interrupts. A 7-minute major cycle will be com- 
pleted in 2 minutes in this manner. The benchmark program 
will downlink the final results and compare the results with 
the known answers. An error will be generated if the 
answers do not match. 


B-19 



b. Real-Time Benchmark Test ; Again/ use the 
benchmark data, but the executive will schedule processes as 
is normally done. 

Thus, AADS will check all computations and scheduling except 
the ephemeris request. 


Number EX016 

Originator K. Saralker Answered by S. Sanders 

Date 8/28/81 Date 8/28/81 

Q: 1. What is the software development procedure on the 

Intel? 

2, How does the Intel LINK program work? 

3. Can the AADS processes share the mathematical sub- 
routine 1 ibrary? 


A: 1. The FORTRAN source is stored on disk on the VAX. A 

utility program ( TBD ) will transfer the source to 
the Intel development system. The source may be 
edited, compiled, and linked. Each process image is 
separately linked and produces a binary file. The 
binary file can be transmitted back to VAX for 
storage or can be stored on a floppy disk on the 
Intel. 


NOTE I a. Intel has fairly good editing facilities, but com 
pilation is very slow. 

b. The object image must be stored on the VAX for 
eventual transmission to AADS Intel computer. 

c. The edited version of the source must be trans- 
mitted to VAX for storage (9/15/81) . 
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Number EX017 


Originator K. Saralker Answered by K. Tasaki 

Date 9/1/81 Date 10/1/81 

Q: Is their any requirement to uplink/downlink AADS code 

for diagnostic testing purposes during flight? If so, how 
will the AADs code be transmitted? 


A: There is no provision for uplinking/downlinking AADS 

code in the current design. However, the new Intel operat 
ing system by Systex should have the capability to store/ 
dump AADS memory when commanded by the ground. The AADS 
code will have to be transmitted through OBC. GSFC will 
determine the total time needed to complete the uplink/ 
downlink, which will be performed in the OBC spare time. 
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Number EX018 


Originator C. Shenitz Answered by K. Tasaki 

Date 9/11/81 Date 11/15/81 

Q; A software clock design is given below. Should AADS use 
this clock to save wall clock time during long simultion 
runs? 

AADS can control the actual testing time by using scaled 
time or by compressing out dead time when the AADS is not 
performing any computations. The scaled time software clock 
uses a scale factor to speed up or slow down AADS time from 
real time. This procedure appears relatively complex, and 
will not be considered. 

The second type of software clock eliminates the time during 
which AADS is idle; therefore, it can only speed • up ( not 
slow down) AADS time. However, this clock can be inter- 
rupted for online diagnostic testing without any loss of 
synchronization between the AADs subprocesses. Suppose AADs 
performs a state update once every 30 seconds, and requires 
only a fraction of a second for star data processing func- 
tions. Thus, AADS typically performs only 3 functions dur- 
ing the remaining time. It reads gyro data every 
64 milliseconds, reads star tracker data every 100 millisec- 
onds, and performs a state propagation every 512 millisec- 
onds. The current timing estimates show that AADS can 
easily perform these three functions in 100 milliseconds or 
less leaving an idle time of nearly 400 milliseconds from 
the 512-millisecond propagation period. The software clock 
will eliminate this idle time by scheduling the three func- 
tions in succession. After each function is completed, the 
software clock "sets" the AADS clock ahead to the start time 
of the next scheduled function. Synchronization with the 
AADS simulator is maintained through a mailbox. If AADs is 
interrupted for online diagnostic testing, then the software 
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diagnostic testing, then the software clock is inactive and 
AADS time does not advance. Therefore, the synchronization 
between AADS and the AADS simulator is maintained. 

Based on the above discussion, AADS time can be speeded up 
by a factor of 4 to 5 during simulation runs on the 
Intel 8086. The factor should be even larger for the VAX 
computer, because the VAX is appreciably faster compared to 
the Intel. 


A: K. Tasaki has indicated that AADS will not use the soft 

ware clock. 



Number lOOOl 


Originator C. Shenitz Answered by K. Tasaki 

Date 6/23/81 Date 6/26/81 

Q: The execution log is required to contain a running rec- 

ord of errors encountered. Should we expand it to include 

a. Reception (acceptance) of various types of data 
(high-level ACK-NAK)? 

b. End of major processes (e.g., star tracking or up- 
date) for the past several minutes? 

Ai This question was submitted just before the release of a 
revision to the Requirements Definition for the AADS Simu- 
lator. This revision, dated June 25, 1981, redefines the 
activity log in such a way that items in category b in this 
question are now included in the log. Mr. Tasaki will con- 
sider part a of the question in making further revisions to 
the definiton of the activity log. 

NOTE ; 1. The ACK-NAK procedures are TBD by GSFC for the 
Intel version (8/24/81) . 

2. See Section 4 for the contents of the activity log 
(4/2/82). 
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Number 10002 


Originator C. Shenitz Answered by K. Tasaki 

Date 6/23/81 Date 6/26/81 

Q; The ability to dump local (COMMON block) variables is 
not required. However, it will certainly be important for 
initial testing and system testing. We can 

a. output local variables directly from their particu- 
lar process (s) during simulation (easy--"diagnostic 
output") . 

or 

b. arrange to pass local variables to the executive 
and then to the output queue by a "Send & Receive" 
mechanism (harder — but can be retained in later 
operational versions) . 

Which method is preferred? 

A: Dumping sections of memory will be a capability avail- 

able to the ground and provided by the operating system. 
(This raises question 10005.) 

The capability of reporting (by the application program) 
local COMMON block contents will be further considered pend- 
ing the presentation by Mr. C. Shenitz of the desirability 
of recovering such data. 

NOTE ; AADS does not have the capability of dumping sections 
of memory (4/2/82). 
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Number 10003 


Originator C. Shenitz Answered by S, Sanders 

Date 6/23/81 Date 6/26/81 

Q: 

1. What is the expected stability of the AADS clock? 

If it is a software clock, is there overhead in reinitializ- 
ing the clock after each timing interval (for example, re- 
issuing a Mark Time) ? 

2. What is the expected granularity of the clock when 
accessing it ? For example, the SMM OBC issued interrupts 
every 15 milliseconds for executive rescheduling; however, 
the granularity of time stored in a particular memory loca- 
tion (the counter) was much coarser. 

Possible ''Clocks"; 

1. Programmable Interval Timer (PIT) (e.g., Intel 8253 
chip) - suitable intervals available for Executive reschedul 
ing interrupts and for fine granularity upon Read access. 

2. Reissuing time interval commands (e.g., Mark Time). 
Overhead involved (tens of microseconds) each time an inter- 
rupt occurs. Periodic reset will be necesisary to eliminate 
accumulated clock bias. 

A: The clock for AADS will have a specific form when the 

AADS microprocessor will be attached to the VAX-11/780 com- 
puter. The AADS simulator software or, in particular, the 
OSS on the VAX will send a pulse (interrupt signal) to the 
AADS machine once every TBD (on the order of 10 millisec- 
onds) . The microprocessor operating system will respond by 
incrementing its running total of these clock ticks. This 
operation will be transparent to all application software. 
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The following capabilities regarding time should be provided 
to application programs by the operating system: 

1. To set and reset the calendar date in year, month, 
day, and milliseconds of a day. 

2. To provide the updated date upon demand by applica- 
tion programs. 

3. To begin timing variable-length time intervals upon 
request and to end such events with an interrupt 
(e.g., the Mark Time macro on the DEC RSX-llM sys- 
tem) . 

NOTE ; 1. See Questions EXOOl, EX014, and EX018 for addi- 

tional information (4/2/82) 

2. The SET CLOCK command has not been implemented in 
AADS (4/2/82) . 


t 

t 

i 

1 
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Number 10004 

Originator C. Shenitz Answered by K. Tasaki 

Date 6/25/81 Date 7/3/81 


Q: In the following pages, the proposed format for messages 

for uplink and downlink is described. The blocking of rec- 
ords within a transmission is described first. This format 
is that used in AODS. Next, a record header format based on 
the one used in AODS is described. It is recommended that 
this proposed header format be used for AADS. 

AADS TRANSMISSION FORMAT 


One Transmission 

/ Record 
Block 1 I 



Block 


Record 

Record 

Record 

Record 



Block N 


'Record n„ 

N 

Sentinel record = all Is 

Header for each record includes the following 

Record number within the block 
Record number within the transmission 
Block number within the transmission 
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Uplink/Downlink Header Format for AADS 


Variable 

Name 

Type 

Dimension 

Description 

SYNCl 

Byte 

1 

Sync number (later, 
spacecraft ID) 

INTYPE 

Byte 

1 

Type of input: 
“ 1, data 
2, command 

INDATA 

Byte 

1 

Type of data or command 

NBLOCK 

Byte 

1 

Running number of this 
record in block 

lAREA 

Byte 

1 

Data area number for in- 
sertion or report 

KEY 

Byte 

1 

Key for later reference 
(for handling a maneuver) 

NTRAN 

1*2 

1 

Running number of this 
record in transmission 

IBLOCK 

1*2 

1 

Running number of this 
block in transmission 

NSIZE 

1*2 

1 

Number of bytes used i,n 
record after header 

TTRAN 

R*8 

1 

Tiitie of transmission 
(GMT) 

1. KEY must 

be set 

to a negative 

number if it is not being 


used. 


2. For inserting data into (uplink) or reporting data from 
(downlink) a specified data area, the following addi- 
tional format will be adhered to: 

a. The first 12 bytes will contain up to 48 contiguous 
indicators of 2 bits each 

b. The indicators will describe the data starting at 
byte 33 of the record in order 
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c. = 0, 1*4 (data is present) 

* Ir R*4 (data is present) 

= 2, R*8 (data is present) 

d. Record contents will be loaded/unloaded by 
EQUIVALENCES 


A: This format appears to be satisfactory. 

NOTE ; 1. The 2-bit code for identifying variable type will 

not be used. The bytes representing parameter 
values will be stored in the tables by using a 
byte transfer routine (8/24/81) . 

2. See Section 4 of this document for AADS message 
formats and contents (4/2/82) . 



Number 10005 


Originator C. Shenitz Answered by S, Sanders 

Date 6/29/81 Date 7/3/81 

Q: In view of the existence of operating system features 

discussed in the answers to questions 10002 and 10003/ 
namely, the capability to dump memory areas and the accumu- 
lation of clock ticks driven by an external source, the 
following question arises: 

Should there be a separate input port to the microproc- 
essor that will be used for all commands and pulses to 
the operating system? 

Reco:mnendation : The separation of input ports should be 

done for the present system to facilitate the development of 
the system on the VAX-11. However, when upgrading to a 
microprocessor-based system, separate input ports may not be 
available. 


A: There will be a separate input port to the microprocessor 

for operating system communications with the external world. 
This will provide for a separation of operating system and 
application communications. 

NOTE; 1. Intel hardware configuration is TBD by GSPC 
(8/24/81). 

2. AADS does not have the capability of dumping sec- 
tions of memory (4/2/82) . 
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Number 10006 

Originator C. Shenitz Answered by F. McGarry and 

K. Tasaki 

Date 7/13/81 Date 7/17/81 

Q? At the Task 924 meeting at GSFC on July 10, 1981, 

Mr. F. McGarry raised the following point: several parts of 
the existing AADS design should be carefully reevaluated to 
justify the present relationships between components and to 
modify the design where necessarv. This evaluation should 
be made with strict attention to AADS objectives and con- 
straints . 

Ini partial response to these remarks, several alternatives 
are presented for the basic design of the sensor data col- 
lection process. Design A is a part of the AADS design. It 
is recommended that the present Design A be kept for the 
advantages cited here. If the disadvantages make it diffi- 
cult to implement AADS, then design B would be used with the 
necessary additions of control logic. 



Design A 
Advantages t 

1. Allows for future (flight software) easy modifica- 
tion for interrupt-driven sensor data acquisition 
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2 


Allows for logical independence and separate sched- 
uling (at present) of sensor data retrieval and 
sensor data processing 


Disadvantages ; 

1. Global COMMON (/SENSOR/ data base) needed for 
transferring sensor data to the processing processes 

2. Overhead (space) needed for separate processes 
(FORTRAN library and system software routines 
repeated, until a sharable library is available) 



Design B 
Advantages ; 

1. Eliminates interprocess communication requirements 
(global COMMON) 

2. Eliminates overhead (space) of a separate process 
(with no sharable library) 



Disadvantages : 


1. More logic and return codes needed for gyro and 
star data processing processes' interfaces with the 
executive; separately scheduled activities (acqui- 
sition and processing) are combined 

2, Any future system requiring interrupt-driven data 
acquisition would require redesign 


A: Design A is selected. 

NOTE ; See Section 1.5 on alternative AADS designs and justi 
fication for the current design (4/2/82) . 



Number 10007 

Originator C. Shenitz Answered by 

Date 7/23/81 Date 

Q: This multipart question concerns data communications 

mainly at the hardware level for the AADS microprocessor and 
the Onboard Support System (OSS) . 

1. Will there be "handshaking” between the two machine 
interfaces for I/O such that data transmitted from the OSS 
will not be lost if AADS delays the issuing of a read (QIO) 
request? 

2. If the ACK and NAK characters are used for synchro- 
nizing transmissions, will the OSS initiate a timeout se- 
quence after sending a (physical) record for waiting for an 
ACK or NAK? Will an error condition result if there is a 
timeout, or will the same record be automatically retrans- 
mitted until an ACK is received? 

Assumptions being made are as follows: 

1. Sufficient "handshaking" between the machines will 
exist for guarding against the loss of transmitted data 

2. If a timeout period exists, it will result in auto- 
matic retransmission. 

NOTE ; 1. The exact handshaking (ACK/NAK) requirements are 
TBD by GSFC (8/24/81). 

2. There are no handshaking procedures at the present 
time. GSS , OSS, and AADS will report errors in 
transmission, but will not ask for retransmission 
(4/2/82) . 
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Number 10008 


Originator C. Shenitz 


Answered by K. Tasaki and 
F. Snow 

Date 7/24/81 


Date 7/23/81 

Q: Should the activity of updating any area of data per- 

taining to attitude computations be deferred until imme- 
diately after completing a major cycle (state update)? 
Should updating take place without regard to present proc- 
essing# assuming that the resulting discontinuity in the 
attitude (or star tracking) history can be tolerated? 

Should updating these parameters be done at times when each 
would be appropriate (after a state propagation, after proc- 
essing gyro data, after star processing, or after a state 
update) ? 


Recommendation; The last alternative is recommended. 


A; AADS will queue uplinked commands that specify a change 
in data locations in designated areas. All these changes 
will be made after the completion of a major cycle (comple- 
tion of a state update) . If star tracking is not scheduled 
(either not initiated or suspended) , the data location up- 
dates may be done after the completion of gyro data proc- 
essing or state propagation. A maximum number ( TBD ) of such 
commands will be queued during any major cycle; if it is 
desired to uplink a greater number of data area updates, 

AADS processing must be halted. Otherwise, the records 
uplinked after the maximum number has been reached will be 
rejected. 

NOTE ; The number of parameters that can be updated during 
processing depends on the time taken to transfer a 
byte (8/24/81) . 
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Number 10009 


Originator C. Shenitz Answered by K. Tasaki 

Date 7/31/81 Date 8/7/81 

0: Should the data capture (DCAP) subsystem be placed in 

the same process as the INPUT subsystem, or should they be 
separate? The advantages of placing the subsystems in the 
same process image are 

1. Reduced system code associated with a separate 
process 

2. Elimination of global area(s) for queueing by DCAP 
of data area changes to be done by INPUT 

3. Increased efficiency in reducing a filled queue 
(e.g., during system startup when data commands from the 
ground may be backed up in the OSS before their consecutive 
transmission to AADS) ; control can flow from DCAP to INPUT 
directly 

The advantage of having separate processes for the above 
systems is that DCAP can be given highest priority, and 
INPUT can be assigned its proper lower priority. 

Recommenda t ion ; Place the subsystems inside the same 
process image. If there are not sufficient task coordina- 
tion and control facilities available in the Intel 8086 
operating 

system, then separate the subsystems into separate processes. 
A: DCAP and INPUT processes are merged. 
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Number lOOlQ 

Originator K. Saralker Answered by S. Sanders 

Date 8/28/81 Date 8/28/81 

Q: Please describe the procedure for transmitting sensor 

data to AADS in the VAX^lntel system configuration. 

A; See References 10 and 11 for general information avail 
able at this time. 



Number ATOOl 


Answered by F. Snow 
Date 8/7/81 


Originator K. Liu 
Date 7/31/81 

Q: Process personnel suggest that the occultation of the 

star tracker by the Sun, the Moon, or the Earth can be con- 
veniently computed by AADS. This has the advantage of not 
having to request the occultation tables from the OBC. But 
the occultation computation needs the Moon ephemeris in ad- 
dition to the Earth ephemeris from the OBC. (The Sun 
ephemeris will be computed internally by AADS.) Will this 
pose a problem for the OBC or the AADS simulator? 

A: AADS will internally compute Sun, Moon, and Earth occul 

tation. Sun and Moon ephemerides will be also computed by 
AADS. 
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Number AT002 


Originator K. Liu Answered by F, Snow 

Date 7/31/81 Date 8/7/81 

Q: Is correction of the star tracker reading due to the 

Earth's magnetic field a requirement for AADS? 


A: Magnetic field correction is not required because it is 

expected to be 1 arc-second. 
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Number AT003 


Originator K, Saralkar Answered by F. Snow 

Date 8/17/81 Date 8/21/81 

Q: It is required to store all stars with magnitudes of be- 

tween 3,0 and 6.4. There are appros^imately 8500 stars in 
this range in the SKYMAP catalog. The autonomous star iden- 
tification document by P. Gambardella shows that there will 
be on average 28.6 stars in the FHST FOV. The following 
questions arise: 

1. Is it required to get the star catalog from SKYMAP? 

2. Can one set the threshold of the star camera to ex- 
clude stars beyond the magnitude of 6,2? 

3. What will be the effect of using stars in the magni 
tude range of 3.0 to 6.2? There will be 1000 fewer stars in 
the star catalog. How will this affect star availability in 
certain less populated regions of the sky? This range re- 
duction will mean a saving of approximately 16 kilobytes. 

A; 

1. The SKYMAP star catalog will be used to generate 
the onboard star catalog. 

2. The star camera can be set at various thresholds 
commanded from the ground, 

3. Ti^ by GSFC. 

NOTE : The AADS star catalog contains 8666 stars in the mag- 

nitude range 2.0 to 6.5, and requires approximately 
55 kilobytes (4/2/82). 
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Number AT004 


Originator K, Saralkar Answered by 

Date 8/17/81 Date 

Q; A preliminary version of the star catalog shows the 
stars arranged by right-ascension values. Each entry in the 
catalog consists of the right ascension, declination, magni- 
tude, and the SKYMAP star number. Therefore, the catalog 
for all stars with magnitudes of between 3.0 and 6.4 will 
require approximately 130 kilobytes of memory for the 
8500 stars. 

1. Can we store the magnitude of a star as a 1-byte 
scaled integer? The star camera resolves stars with a mag- 
nitude difference of 0.25 units. Therefore, a one-byte 
field will be sufficient to represent the star magnitudes 
with required accuracy. This will save 3 bytes per star 
entry or approximately 24 kilobytes for the entire catalog. 

2. AADS is required to output the SKYMAP catalog num- 
bers for the identified stars. CSC will write a program 
(CATLOG) to create the onboard star catalog from the SKYMAP 
catalog for a given epoch. The onboard star catalog will be 
formatted as an array with each entry describing a star. 

The program CATLOG will also produce a table (TABLE) giving 
the array index in the onboard catalog versus the SKYMAP 
number for all stars. AADS will output the internal star 
reference number (array index) to the ground, and GSS can 
then find the actual SKYMAP number by means of a simple 
table lookup from TABLE. This procedure will eliminate 

4 bytes per star that would be otherwise required to store 
the SKYMAP number in the onboard catalog. A memory saving 
of 4 bytes per star or approximately 34 kilobytes will be 
possible. Is this procedure acceptable? 

NOTE ; The AADS star catalog contains 8666 stars in the mag- 
nitude range 2.0 to 6.5, and requires approximately 
55 kilobytes (4/2/82). 
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Number AT005 


Originator K. Saralkar Answered by 

Date 8/17/81 Date 

0* An alternative star catalog structure is described here. 
An onboard star catalog will be divided into 360 subcatalogs. 
A given subcatalog will contain all stars with their right 
ascensions in a Ipdegree range. For example, the 35th sub- 
catalog will contc^in stars for which 34 degrees < right 
ascension of the star < 35 degrees. The right ascension 
is divided into the integral and the fractional part. For a 
given star, the integral part of the right ascension will be 
the subcatalog index, and the fractional part will be stored 
as a 2-byte integer value. 

For example, the entry 2389 in the 73rd subcatalog will rep- 
resent a star with a right ascension of 72.2389 degrees (the 
73rd catalog contains stars with a right ascension of 72 de- 
grees or more) . The declination will still be given by a 
4^byte field. This procedure will save 2 bytes per star 
entry or nearly 17 kilobytes for the entire star catalog 
containing 8500 stars. However, it will take more time to 
decode the star catalog. In addition, the star catalog gen- 
eration program will be more complicated because of the 
additional encoding involved. A 7-byte entry per star 
(2 bytes for right ascension, 4 bytes for declination, and 
1 byte for magnitude) will ^allow the entire catalog {magni- 
tude range of between 3.0 to 6.4) to be stored in approxi- 
mately 60 kilobytes. 

NOTE * The AADS star catalog uses the above design. It con- 
tains 8666 stars in the magnitude range 2.0 to 6.5 and 
requires approximately 55 kilobytes {4/2/82) .. 
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Number AT006 


Originator K. Saralkar Answered by F. Snow 

Date 8/17/81 Date 8/21/81 

Q: AADS will compute the occultation o£ the star cameras by 

the Sun, the Earth, and the Moon. Spacecraft-to-Earth 
ephemeris will be supplied by the OBC (OSS) . Sun ephemeris 
data is computed by using the utility routine SUNIX, and the 
Moon ephemeris is computed by using the utility routine 
SMPOS, SUNIX is available in the library ATTIT.ATTMAIN.UTIL, 
PACK, FORT; SMPOS is also available in the same library. 

Various constants needed to compute the occultation and the 
three tolerances (for Sun, Earth, and MOon, respectively) 
will be added to the list of data base variables. This 
procedure will eliminate the communication between the OBC 
and the AADS computer required for the occultation request. 
The occultation computation will be moved from the OBC to 
AADS. This is a simple calculation, and it is not expected 
to affect the AADS schedules. This is scheme A. 

In an alternate scheme (scheme B) , the OBC will compute the 
occultation information based on the Sun, Earth, and Moon 
ephemerides. A 1-byte flag indicating the occultation of 
both star cameras by the Sun, Earth, or Moon will be added 
to each ephemeris entry in the ephemeris sent by the OBC to 
AADS. This scheme has several advantages. 

1. The OBC has to generate the spacecraft ephemeris 
regardless of which program computes the occultation indi- 
cator. 

2. A separate occultation request is unnecessary since 
the occultation flag is sent along with each ephemeris 
element. 

3. AADS scheduling is much easier when the occultation 
computation is eliminated. 

B-45 

c-^l 



However, the tolerances for occultation will be stored in 
the OBC's memory and will have to be changed (if needed) 
using a separate OBC uplink. 

Which scheme should be used? 

A: Use scheme A for the VAX version. As far as possible, 

AADS should not depend on othef programs or computers. 
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Number ATOP 7 

Originator K. Saralkar Answered by 

Date 8/17/ai Date 

Q: The current version of SMPOS will give Moon ephemeris 

with an accuracy of 0.25 degree (arc-length) until 1981, 
After this time, the accuracy will deteriorate. The maximum 
error for SUNIX is 0.012 degree arc-length for all times 
from 1971 to 1981. The epoch is 1900; therefore, the ac- 
curacy will remain close to 0.012 degree arc-length for 
times beyond 1981. 

1. What is the accuracy of SMPOS beyond 1981? 

2. Can we use SMPOS for Moon occultation? 

3. Can we use SUNIX for Sun occultation? 

4. Can we use a Sun ephemeris obtained from SUNIX for 

the aberration correction? 

NOTE ; Routines SMPOS and SUNIX can be updated by updating 
epoch and other constants used in the routines. 

J. Rowe (CSC) has done some analysis required to 
update these routines for the required time periods 
(8/24/81). 
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Number AT008 


Originator K. Saralkar Answered by 

Date 8/18/81 Date 

Q: AADS uses a pairwise star matching technique for identi- 

fying stars. If the initial attitude is uncertain by a large 
amount (2 degrees) , each observed star may have several can- 
didate stars in the star catalog. All candidates for all 
observed stars are carried forward for identification; then 
pairwise matching between candidate stars is performed to 
resolve ambiguities. 

The following questions arise; 

1. Is direct matching necessary in addition to the 
pairwise technique? 

2. What is the upper limit in attitude uncertainty at 
which the pairwise matching will fail? 

3r What should be done for stars that cannot be iden- 
tified using pairwise matching? Is triplet matching 
r.fquired for this or other cases? 

NOTE ; 1. The SMM ground program uses triplet matching 
(8/24/81) . 

2. AADS uses a modified pairwise matching scheme when 
the attitude uncertainty exceeds user specified 
tolerance. AADS automatically reverts to direct 
matching when the attitude uncertainty satisfies 
the user specified tolerance. AADS does not use 
a triplet matching scheme (4/2/82) . 
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Number ATOP 9 

Originator K. Saralkar Answered by 

Date 8/18/81 Date 

Q: Some of the stars in the star catalog may have near 

neighbors that will make identification difficult (ambig- 
uous) . The observation corresponding to such a pair may not 
be used for a star update. These pair stars can be identi- 
fied by flagging the entries corresponding to the two stars, 
for example, by using a negative magnitude value. Is this a 
required procedure? 

NOTE ; AADS uses a negative magnitude value to indicate near 
neighbors (4/2/82). 



Number ATOlO 


Originator K. Saralkar Answered by F, Snow 

Date 8/18/81 Date 8/24/81 

Q: Gyro-propagated attitude is output by AADS for data an- 

notation purposes at a nominal period of 512 milliseconds. 

It is possible that because of some delay the attitude up- 
date process will be running when gyro processing and propa- 
gation is scheduled. The alternatives are to complete the 
attitude update and delay the gyro propagation, or to sus- 
pend the star update, complete gyro propagation, and resume 
attitude update. 

1. Which alternative should be used? 

2. Gyro propagation may be delayed (probably a few 
milliseconds) when a high priority process (command input) 
causes the gyro propagation to be suspended. Thus, the gyro 
propagation computation and data annotation will be delayed. 
Is this acceptable? 

A: 

1. Suspend attitude update and complete gyro propaga- 
tion since data annotation is important. 

?. The delay is acceptable since the attached time for 
the computed attitude..is not changed, even though the actual 
computation is delayed. 
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Number ATOll 

Originator K. Saralkar Answered by E. Lefferts 

Date 8/18/81 Date 9/18/81 

0* The nominal period of gyro propagation is 512 millisec- 
onds. E. Lefferts had indicated that the 30-arc-second (3a) 
attitude accuracy required may be maintained at a gyro prop- 
agation period of 1024 milliseconds. What is the expected 
attitude accuracy when the present Kalman filter is used at 
a period of 1024 milliseconds? 

A* The accuracy is TBD by GSFC personnel. 



Number AT012 


Originator C. Shenitz Answered by 

Date 8/17/81 Date 

Q: In the existing AADS design document (March 1981 ) , the 

so-called stabilized (Joseph) form of covariance update is 
described for the Kalman filter algorithm to be implemented. 
This is done to satisfy the design criteria of stability 
with regard to roundoff errors (see Sections 4.9.1, 4.9.2, 
and Section 5) . 

However, the attached excerpts from the JPL technical memo- 
randum by C. L. Thornton and G. J. Bierman make the follow- 
ing points; 

1. When double-precision arithmetic is used, numerical 
errors due to roundoff are of no major significance (in an 
interplanetary trajectory filtering problem) 

2. The stabilized (Joseph) form--in a computationally 
efficient implementation--is still subject to numerical 
roundoff instability when single-precision variables are 
used. 

3. The conventional Joseph form specified in the de- 
sign is computationally very expensive and not even used in 
the cited study. 

T 

4. The Bierman-Thornton U-D (UDU ) algorithm is 
stable and computationally economical. 

5. Implement the conventional covariance update algo- 
rithm instead of the Joseph form as shown 

Pj(+) = (I - 

which is straightforward and easy to code and test. If 
numerical instability (loss of positive definiteness of the 
covariance) appears to be present in simulation testing, 
then the UDU factorization can be implemented in the 
final version. 
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CSC recommends that this algorithm be studied further to 
determine whether it will satisfy AADS requirements. 

NOTE: AADS uses the routine RECUR from the file ATTIT. 

ATTMAIN.UTIL. PACK. FORT on the IBM 360/95 computer. 

This routine is used to process all available stars to 
compute a single correction to the current estimate of 
the state (4/2/82) . 



Number AT0I3 


Originator E. Lefferts Answered by K. Saralkar 

Date 11/1/81 Date 11/10/81 

Q: Can we separate state and covariance propagation? In 

the current AADS design, state propagation and covariance 
matrix propagation is performed after n gyro data processing 
intervals. Gan the AADS design be changed so that the co^ 
variance matrix propagation is performed every m state pro- 
pagations where m is typically 100? 


A; The covariance matrix can be propagated every m state 
propagations after several changes in the gyro data proc- 
essing and propagation code. In addition, the state 
covariance matrix should be updated just before star 
identification regardless of the current value of m, the 
covariance matrix propagation factor. This out of cycle 
propagation is required to provide the best estimate of 
attitude uncertainty for selecting the star identification 
method . 

The following variables will be added to the COMMON areas. 
STATIC COMMON 

MCOVAR Covariance matrix propagation interval factor. 

Covariance matrix propagation is performed 
after MCOVAR state propagation intervals. De- 
fault value 100. 

JCOVAR Interval factor for synchronizing state and 

covariance matrix propagation during the time 
just before star identification. For N* JCOVAR 
gyro data processing intervals before star 
identification, the covariance matrix will be 
propagated whenever state propagation is 
scheduled. The default value should be 2 or 3 
for JCOVAR to ensure a current covariance 
matrix, which is needed to calculate the 
attitude uncertainty. 
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GLOBAL COMMON 


Flags and other counters needed so that the execu- 
tive can do the extra scheduling. 

PRO PAG LOCAL COMMON 


SATl 

EAAl 


Sum of incremental times 
Sum of incremental angles 
other variables 


{ variable used for 
state propagation 


EAT2 Sum of incremental times 

ZAA2 Sum of incremental angles 

. other variables 

• ^ 


( variables needed for 
separate covariance 
propagation 


Actual Code Changes 

1. Change one or two executive routines to perform the 
additional covariance matrix propagation scheduling. 


2. Add logic to several GYPROC and PROPAG routines to 
store additional variables for covariance matrix propaga- 
tion. PROPAG will keep an internal counter and perform 
covariance matrix propagation after MCOVAR state propagation 
intervals. GYPROC will also reset all counters and other 
variables such as ZAT2, ZM2, etc. 
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APPENDIX C - WEEKLY DESIGN REVIEW DOCUMENTATION 


This section contains letters that document the weekly de- 
sign reviews. 

The information contained in these letters has been incor- 
porated in the body of the document; however, the letters 
are reproduced here to document the evolution of AADS de- 
sign, In some cases, the letters contain incomplete or 
inaccurate information because sufficient information was 
not available at the time the letters were written. 

Sections 1 through 5 of this document should be consulted to 
resolve ambiguities or discrepancies. 


Review Date 

Letter Date 

Page Numbe 

June 1 

June 5 

C-3 

June 9 

June 22 

C-5 

June 26 

July 14 

C-7 

July 10 

July 17 

C-9 

July 17 

July 21 

C-12 

July 31 

Aug. 20 

C-14 

Aug . 7 

Aug. 20 

C-lu 

Aug. 14 

Aug. 20 

C-18 

Aug. 21 

Aug .25 

C-21 

Aug. 28 

Sept. 1 

C-23 

Sept . 1 

Sept . 8 

C-25 

Sept. 1 

Sept. 9 

C-27 

Sept. 4 

Sept . 9 

C-30 

Sept. 18 

Oct. 1 

C-32 

Sept .25 

Oct. 1 

G-34 

Oct. 2 

Oct, 5 

G-36 

Oct. 7 

Oct. 13 

C-38 

Oct. 14 

Oct, 19 

0 

1 
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COMFUTSH SCIEJNCSS CORPOStATION 

SYSTEM SCIENCES DIVISION (301)589-1545 

8728 COLESVIULE ROAD • SILVER SPRING, MARYLAND 20910 

June 5, 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E-225 
and 

Mr. F. Snow 
Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS 5-24300 

Task Assignment 92400 

Autonomous Attitude Determination System 
Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC’s ,^i*dcr3tc.nding of '’“cisions 
made at a meeting held on June 1, 1981, at GSFC^ to review and 
clarify the software requirements for the microprocessor-based 
autonomous attitude determination system (AADS) . Present were 

F. McGarry and K. Tasaki of GSFC; and S. Cheuvront, V. Church, 

G. Page, and K. Saralkar of CSC. 

F. McGarry reviewed the concept of autonomous attitude determina- 
tion and the way it fits in with the 'packetization' (autonomous 
processing for attitude, orbit, time, and science data). K. Tasaki 
reviewed the AADS system design created during the previous task 
(Task 92300) . The following decisions were made during discus- 
sions: 

• Attitude computation requirements and analysis are mainly 
complete except that the attitude accuracy requirements 
have not been completely specified. 

• The design for the attitude computation function is mainly 
complete and only needs a light review, 

• The design for the input and output subsystems is not com- 
plete because the system requirements have not been com- 
pletely specified. 
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Mr, K. Tasaki 
Mr. F. Snow 


- 2 - 


June 5, 1981 


• A specification summary document is needed to consolidate 
all the facts needed to complete the AADS design. 

• The current task assignment will be amended to require com 
pletion of detailed design for a skeleton system (shell) 
which will include the executive, input, and output sub- 
systems. The requirement to code and test the shell will 
be deleted. 

• Regular weekly meetings will be held at GSFC to monitor 
task progress. 


Yours truly. 



Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 
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F, McGarry M. Plett 

E. Lefferts S. Cheuvront 

G. Page 
K. Liu 
C. Shenitz 
G. Klitsch 


COMFOTSa SGIEMCFS CORPOHATION 

SYSTEM SCIENCES DIVISION (301)589-1545 

8728 COLESVIULE ROAD • SILVER SPRING. MARYLAND 20910 

. June 22 , 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 
Bldg. 23, Room E-225 

and 

Mr. F. Snow 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS- 524300 

Task Assignment 92400 

Autonomous Attitude Determination System 
Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC 's understanding of the topics dis- 
cussed at a meeting held on June 9, 1981, at GSFC to review the 
Autonomous Attitude Determination System (AADS) simulator and the 
attitude propagation and update equations. Present were E. Lefferts, 
F. Snow, K Tasaki of GSFC; and K. Liu, G. Page, and K. Saralkar of 
CSC. Below is a summary of the information exchanged at the meeting. 

1. The nominal period of gyro processing and attitude propaga- 
tion is 0.512 seconds. It may be possible to compute atti- 
tude with the required accuracy using a larger period for 
gyro processing. Mr. Lefferts will determine the upper 
limit on the period. 

2* The AADS simulator is made up of 3 functions: 

• Ground Support Subsystem (GSS) 

• Onboard Support Subsystem (OSS, also called OSFS in 
other documents) 

e Sensor Data Subsystem (SDS) 

3. AADS will perform some validation of the commands and data 
input by the user. 

4. OSS will generate ephemeris and occultation information as 
required. A subset or segment of this will be stored in the 
AADS memory as a table. AADS will read in a new segment 
when it reaches the last time in the current segment. The 
exact form of the occultation table is to be determined. 
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K. Tasaki -2- June 22 , 1981 

F . Snow 


5. AADS will prepare any requested output as a header record 
followed by n data records. OSS will transmit (downlink) 
this block of records to the ground without further proc- 
essing. 

6. GSS, OSS, SDS, and AADS will need a consistent source of 
time which may be a software clock in each subsystem, plus 
a hardware clock. The form of this software clock and 
time synchronization mechanism is not completely speci- 
fied. 

7. SDS will store the gyro data in a buffer. The data will 
be updated every 64 milliseconds and will always be avail- 
able to the AADS, The star tracker data, except for the 
temperature, will also be stored in a buffer and will be 
updated at smaller intervals. 

8 . The following questions must be answered before gyro and 
star tracker data can be time tagged properly. 

• What type of clock will be used by the system? 

• Since gyro data times will be in error by 64 mil- 
liseconds (maximum) , how will this affect attitude 
propagation? 

• Is there a (constant or otherwise) time delay be- 
tween the end of occultation and the start of star 
tracker output? 

• How will the AADS label the time of star temperature 
data in relation to the rest of star data? (The star 
temperature may be available asynchronously.) 


Yours truly. 



Dr. K, Saralkar 
Task Leader 

Attitude Systems Development 

KSrgsp 

copies: GSFC 

F. McGarry 
E. Lefferts 


CSC 

M. Plett 
S . Cheuvront 
_ G. Page 
K. Liu 
C. Shenitz 
G. Klitsch 


COMPUTER SCIENCES CORPORATION 

SYSTEM SCIENCES DIVISION (301)589-15 4 5 

8720 COUESVILLE ROAD • SILVER SPRING, MARYLAND 20910 

July 14, 1981 


National Aeronautics and Space Administra.tion . 

Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention; Mr. K. Tasalci 

Code 581.2 

Bldg. 23, Room E-225 

and 

Mr. F. Snow 

Code 582.3 

Bldg. 23, Room E-239 ... 

Subject: Contract NAS-524300 -. . 

Task. Assignment 92.400. 

Autonomous . Attitude Determina:tion. System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC * s . understanding of the topics dis- 
cussed at a meeting held..on .June. 26, .19J.1,.. at. G^SFC to, review task 
status. Present^were-F-. Snow and K. -Tasak4r of- GSFC;~ &. Sanders-^..'-^ 

of Systex; and G* Klitsch, G-. Page, K. —Sara Ikar, and C. .Shenitz of ... ... 

CSC. Following is a summary of -information given by .Systex and 
GSFC personnel in response to CSC questionsj. ., . 

• The Intel/8086 FORTRAN compiler-will.be available, in the 
August to October, 1981 period.. 

There is no suitable cross-compiler for the -Intel/8086 on 
the VAX-11/780 computer. The current cross-compiler does 
not support double precision arithmetic and does not inter-.. ... . 
face with the Intel/8087 numeric data processor chip. 

• The Intel/8086 operating system will support time-of-day 
and timing interrupt functions which will be similar to 
the functions; available on the VAX-11/78.0 computer. 

• Gyro and star data (including star temperature data) .will 
be available in digital form. AADS will access these data 
in a synchronous manner from a* buffer area. 
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Mr. K. Tasaki 
Mr . F . Snow 


- 2 - 


July 14, 1981 


• A preliminary version of the AADS. Simula tor will be avail- 
able by September 30, 1981, and will be used for AADS test 
ing purposes. 
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Yours truly. 


Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 


CSC 


F . McGarry 
E . Lef f erts 


S . Cheuvront 
G . Page 
K. Liu 
C. Shenitz 
G. Klitsch 



COMPUTER SCIENCES CORPORATION 

SYSTEM SCIENCES DIVISION (301). 589-1545 

8728 COLESVILLE ROAD • SILVER SPRING, MARYLAND 20910 

July 17, 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E-225 
and 

Mr. P. Snow 
Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS-524300 

Task Assignment 92400 

Autonomous Attitude Determination System 
Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics discussed 
a meeting held on July 1981, at GS^<^ d-i.snus.s schedules and 
task status. Present were F. McGarry and F. Snow of GSFC; and 
G. Klitsch, G, Page, C. Shenitz, and K. Saralkar of CSC. 

CSC recommended that the AADS be implemented in three builds. The 
first build will include detailed design for the executive, input, and 
output tasks. This skeleton system which can interface with the exist 
ing simulator will be implemented on the VAX-11/780 computer. The 
Build 1 schedule is as follows: 

Recommended B u ild 1 Schedule 

Design 
Review 

Implementation 

Additional capabilities such as input command and data validation, de- 
tailed output, and extensive error handling will be implemented in 
Build 2, The detailed design of the attitude computation tasks will 
also be completed in Build 2 which will end on October 30, 1981. The 
attitude system will be implemented in the Build 3 which will end on 
November 30, 1981. 
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8/14/81 

9/1/81 

9/30/81 


Mr. K. Tasaki -2- . July 17, 1981 

Mr . F . Snow 


During the ensuing discussion the following points were made: 

• The handwritten specifications summary will be available for 
the design reviews . 

• CSC will periodically submit the system design to the ATR 

for review and comments. In addition, informal design reviews 
will be held at GSFC before the Critical Design Review (CDR) . 

• CSC vjill present at the CDR the functional specifications for 
AADS and the ability of the design to meet those specifications. 
The emphasis will be on the main functional flow through the 
system rather than the detailed computations. 
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• Viewgraphs will not be required for the CDR. 


F., McGarry raised several questions about the current design with 
respect to memory and time constraints, implementation techniques, 
and design flexibility to meet the changing requirements. CSC per- 
sonnel justified the current design as follows: 

• The breakdown of AADS into an executive, input, computational, 
and output tasks is based on functionality. The further break- 
down of the computational task into five tasks (gyro processing, 
^ro propagation, star data, star identification, attitude up- 
date) is to generalize the system. Because these five functions 
may be performed ?.t d.ifferent ar*^ frequencies, a desiign 

decision was made to keep the scheduling logic at the executive 
level . 


] 
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• The subtasks were designed to meet the 64K byte memory constraint * 
and to meet the design goals of functional integrity (one func- ^ 
tion - one task) . 


• The earlier design (completed under Task 92300) showed that the 
AADS will meet timing constraints. It showed that nearly 250 
milliseconds of the allotted 512 milliseconds will be available 
each cycle through AADS. In addition, E. Lefferts has indicated 
that the AADS may be able to achieve the 30 arc-second attitude 
accuracy requirement at a gyro-processing period of 1024 milli- 
seconds. Further, actual CPU times will depend on the FORTRAN 
compiler used for the Intel/8086 microprocessor. Thus memory 
constraints and design considerations were given more weight at 
this stage of the design. 

• The current design is flexible due to the logical and functional 
breakdown and should allow incorporation of most new or changed 
requirements without a major redesign. 

• Memory and time optimization, if required, should be attempted 
after the system is developed, particularly for a prototype 
system. 
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• CSC will reevaluate the design of the computational subtasks 
during Build 2. The design will be modified if required in 
light of additional knowledge and experience gained. 
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Yours truly. 



Dr. K. Saralkar 
Task Leader 
Attitude System 


Development 


CSC 

S. Cheuvront 
G. Page 
K. Liu 
C . Shenitz 
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National Aeronautics and Space Administration 
Goddard Space Plight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E-225 
and 

Mr. P. Snow 
Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS-524300 

Task Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the tooics dis- 
;^-l- a malting or J”Jy I"?, 1981, at GSFC to rcvicT tack 

status. Present were P. McGarry, P. Snow, and K. Tasaki of GSFC; 
S. Sanders of Systex; and G. Klitsch, G. Page, K. Saralkar, and 
C. Shenitz of CSC. 

CSC personnel reviewed the original AADS design and presented an 
alternate design. The alternate design combines several tasks 
into single tasks in an attempt to reduce the overhead associated 
with the large number of tasks present in the original design. 
During the discussion that followed, S. Sanders indicated that 
CSC's questions about upper and lower limits on task size, 
whether the mathematical subroutine package is shared by all 
tasks or duplicated, and whether or not global COMMON areas 
are included in the address space of €iach task can be resolved 
only after the Intel/8086 firmware becomes available. After com- 
paring the two designs, the attendees agreed to use the original 
design to develop the prototype system on the VAX-11/780. The 
design will be reevaluated later in light of the experience gained 
with the prototype system and information on the Intel/8086 firm- 
ware. 
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CSC and GSFC pers50nnel made the following design decisions in 
response to CSC questions EX007 through EXOIO. 


• The maneuver schedule will not be uplinked. AADS will 
sense a maneuver by checking for a higher gyro rate. 

• AADS will suspend star data processing during a maneuver. 
Star data collected before the beginning of the maneuver 
will be discarded. 


• AADS will request a new occultation table from the on- 
board computer after a maneuver. The request will con- 
tain the current attitude and the time span for the oc- 
cultation table. Star data processing will, be resumed 
after checking the new occultation table. 




AADS scheduling will be accurate to 10 milliseconds be 
cause of system clock limitations. 

Yours truly. 




Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 
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August 20, 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bidg. 23, Room E-225 
and 

Mr. F. Snow 

Code 582.3 

Bldg. 23, Room E-23S 

Subject: Contract NAS-524300 

Task Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at a meeting held on July 31, 1981, at GSFC to review task 
status. Present were E. Lefferts, F. Snow, and K. Tasaki of GSFC; 
and G. Klitsch, K. Liu, K. Saralkar, and C. Shenitz of CSC. 

G. Klitsch reviewed the top-level design for the executive task. 
Ground commands to AADS and exectutive action for these commands 
was discussed. The STOP command will cause the AADS to complete 
the update process, downlink the last output, and stop gyro and 
star processing. The AADS will wait for the next command. The 
HALT command suspends star processing; gyro processing and propa- 
gation activities continue. The operating system will maintain 
ail time-related functions. The time of day will be available to 
the AADS from the operating system. The operating system will also 
synchronize its clock after a "synchronize clock” command from the 
ground to the operating system. However, certain schedule tables 
which the executive maintains should be updated as a result of the 
time synchronization. In addition, this means that the SET CLOCK 
command specified in the requirements is not meaningful. Systex 
personnel will study the problem of time synchronization further. 

eJ Lefferts suggested that a modified pairwise technique should be 
employed so that the AADS will be able to compute attitude when the 
initial attitude estimate is in error by a large amount (2-3 de- 
grees) . All possible candidates for all observed stars will be 
stored in memory. A pairwise matching scheme using each candidate 
star will provide positive star identification. Task personnel 
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feel that the current top-level design can be modified easily to 
permit this enhancement; however, the detailed design of the new 
pairwise matching algorithm will require additional design effort 
during the follow-on task. GSFC and CSC personnel will study the 
star identification methods to determine whether the attitude com- 
putation requirements are satisfied in 1) normal case nominal at- 
titude, 2) attitude drifting away from the nominal attitude; 3) at- 
titude acquisition (approaching nominal attitude) . 

E. Lefferts also suggested that the AADS can be completely autono- 
mous by the addition of a Sun sensor/magne tome ter (Sun/Mag) or 
Infrared sensor/Sun sensor (IR/Sun) attitude computation system 
to AADS. CSC personnel feel that this will require a major re- 
design effort, particularly, to reevaluate time and memory re- 
sources. Therefore, such a capability should be added as a major 
enhancement to the AADS during a future task. 

Occultation of star cameras by Gun, Earth, and Moon was discussed. 
In the current design, the OBC computes and transmits an occulta- 
tion schedule to AADS upon request. The ATR requested that the 
task use an alternate means (such as the bright object sensor (BOS) 
associated with the star camera) to obtain this information to min- 
imize AADS-to-OBC communication. Task personnel will study this 
problem , 

In response to a CSC question, F. Snow replied that the minimum 
gyro propagation period is 512 milliseconds. However, gyro data 
will be sampled (approximately) every 64 milliseconds or move. 

The SENSIN task should check for gyro data saturation at that 
frequency. 
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Yours truly. 



Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 


CSC 

S . Cheuvront 
G. Page 
K. Liu 
C. ShenitZ 
G. Kiitsch 
Y. Frenkel 
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National Aeronautics and Space Administration 
Goddard Space Flight 'Center 
Greenb'elt, Maryland . -20771 

Attention: Mr. K. Tasaki 

Code 581.2 
6ldg. 23/ Room E-225 

and 

Mr. F. Snow 
Code 582.3 

Bldg. 23/ Room E-239 

Subject: Contract NAS- 5 23 4 00 

Task Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at a meeting held on August 7, 1981, at GSFC to reveiw task 
status. Present were F. McGarry, F. Snow, and K. Tasaki of GSFC; 
K. Liu, G. Page, K. Saralkar, and C. Shentiz of CSC. 

C. Shenitz reviewed the design of the input and output tasks. In 
response to an earlier request from the ATR, data flow diagrams 
showing external and internal task interfaces were prepared and re 
viewed at the meeting. In addition, the physical procedure for 
reading ground commands was discussed in detail. The following 
sequence describes the main features of the input task. 

• Upon activation of AADS, the input task issues a real re- 
quest to the OBC and waits for a command from the ground 
(via OBC) , or an ephemeris transmission from the OBC. AADS 
processing goes on normally while the input task waits at a 
high priority. 

• The operating system (for the attitude computer) receives a 
transmission from OBC and stores it in a buffer specified in 
ihe read request, and then 'wakes up* the waiting input sys- 
tem with a read completion interrupt. Any active task is 
suspended. The operating system also sends the transmission 
acknowledged signals (ACK/NAK) as specified by the communi ca- 
tions protocol. 


« 
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• The input task decodes the commands and sets flags for the 
executive. The ephemeris table is updated if requested 
ephemeris was received, and data for table update are stored 
for later processing. Some minimal input validation is per- 
formed. At this stage the input system issues another read 
request and suspends itself. AADS resumes normal processing 
and any waiting or suspended tasks are resumed according to 
their priorities. 

• The executive task will schedule the input task at the end 
of a major cycle (attitude update completed) to validate 
ephemeris and table updates, and to modify the tables. 

Tables are modified at the end of a major cycle to avoid 
possible disruption of attitude computation during a major 
cycle. If the table areas must be modified immediately, 
then the ground will send commands to STOP processing, up- 
date table areas, then START processing. It is expected that 
such action will be required infrequently. 

• AADS generates error messages when received transmissions 
fail validation checks. Other than these error messages, 
regular acknowledgement of input is not planned at this time. 
This is done to minimize communication with the OBC, 

• System personnel and AADS simulator development personnel 
will determine whether ACK-NAK procedures are required at 
the applications level between all communication interfaces, 
including the output from the AADS to the OBC. 

CSC recommended that a software clock be used for both the AADS 
and the AADS simulator so that processing can be speeded up during 
testing. The software clock will contain a scale factor that will 
allow the clock to speed up in relation to the external world. 

This will also allow task personnel to use the online dynamic de- 
bugging technique (DDT), for testing. Use of DDT with a realtime 
clock is not possible because of the synchronization requirements. 
In summary ^ the software clock will enable CSC to improve testing 
efficiency without requesting many high priority jobs or program- 
mer present blocktimes. The ATRs and GSFC personnel developing the 
AADS* simulator are considering this suggestion. 


Yours truly. 



Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 
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National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 
Bldg. 23, Room E-225 

and 

Mr. F. Snow 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS-524300 

*rask Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at a meeting held on August 14, 1981, at GSFC to review 
task status. Present were L. Jun, R. Shwenk, F. Snow, and 
K. Tasaki of GSFC; S. Sanders of Systex; :ind G. Klitsch, K. Liu, 

K. Saralkar, Y. Frenkel, and C. Shenitz of CSC. 

Si. Sanders discussed data transmission and a system clock. Data 
can be transmitted between the VAX-11/780 and the Intel/8086 over 
two sets of 16-bit, full duplex paths. Ground commands, data, and 
ephemeris will be transmitted as 256-byte blocked records. Blocking 
will be done by the applications program according to a predefined 
format. FORTRAN callable utilities will be supplied by Systex for 
transmitting (writing) and receiving (reading) data over the commun- 
ication's paths . 

These routines (to be supplied) will specify the buffer area for 
data, number of records to be transmitted/received, and a unit for 
data transmission/reception. The read routine will read incoming 
records in a loop with WAIT/NOWAIT and timeout options . The time- 
out option will allow the applications software to abort the read 
if all expected records are not received in a given time due to 
either loss of synchronization or transmission failure. The appli- 
cations software should validate transmissions (checksxoms, sync 
bytes, etc). The actual transfer of a single record will take ap- 
proximately 6.4 milliseconds at approximately 50 microseconds per 
word of two bytes . 
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The data transmission scheme outlined above will also be used for 
transmitting AADS simulator generated sensor data to the AAD'S . The 
current design assumes (as discussed in a previous design walkthrough) 
that the sensor data will be written to a buffer in AADS by a Remote 
Interface Unit (RIU) using a direct memory access (DMA) or memory 
sharing scheme. This would take a negligible amount of time from 
the AADS point of view. The current design will have to be modified 
because of the hew requirements. The gyro data are available every 
64 milliseconds, and the star tracker is available every 50 milli- 
seconds. The data transfer time (6.4 milliseconds every 64 milli- 
seconds) will be excessive if the standard 256-byte record is used 
for sensor data transmission. A smaller record (approximately 30 
bytes) will take between, 1 to 2 milliseconds. CSC will study the 
new data transmission procedures to determine the modifications to 
the current design. 

The Intel/8086 operating system will maintain the time of day for 
the AADS scheduling and time tagging requirements. The time of 
day will be initially loaded when the Intel operating system is 
loaded by VAX. The clock will be maintained with a periodic (ap- 
proximately 10 milliseconds) pulse sent over a separate line be- 
tween the Intel and VAX computers . The RESET CLOCK command is 
thus unnecessary for this scheme and will not be required for the 
prototype software. CSC personnel recommended that a single, cen- 
tral time base (clock) with a 1 millisecond pulse should be used 
ih the final version. The single time base is needed to maintain 
consistent times for all computers onboard the spacecraft, and the 
1 millisecond resolution is required to satisfy the requirement of 
processing gyro data every 64 milliseconds. This requirement may 
b4 satisfied in the current version by using a separate 1 milli- 
second clock to maintain small time differences after the main 
lb millisecond pulse arrives. 

S. Sanders will investigate and respond to questions on: 

• size and capabilities of the mathematical subroutine package 

• arithmetic exceptions 

• addressing exceptions 

G. Klitsch reviewed the top-level design of the executive task. 

Data flow diagrams were presented to indicate major external and 
internal interfaces, and flowcharts were used to demonstrate ex- 
ecutive scheduling of tasks during normal processing and maneuver 
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and occulta tion periods. Attendees discussed occultation coinpu* 
tation and star catalog size and structure. These points will be 
documented later as answers to questions. 
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Yours truly , 

Dr . K . Saralkar 
Task Leader 

Attitude Systems Development 


CSC 

Si Cheuvront 
G . Page 
K. Liu 
C. Shenitz 
G. Klitsch 
Y. Frenkel 
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National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E-225 
and 

Mr. F. Snow 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS-524300 

Task Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at a meeting held on August 21, 1981, at GSFC to review task 
status. Present were L. Jun, F. Snow, M. Stark, R. Shwenk, and 
K. Tasaki of GSFC; S. Sanders of Systex; and Y. Frenkel, G. Klitsch, 
K. Liu, K. Saralkar, and C. Shenitz of CSC. 

S. Sanders discussed data transmission and the Intel operating sys- 
tem. Gyro and sensor data will be stored in the AADS memory using 
direct memory access (DMA) , because of the excessive input/output 
(I/O) time needed to send the data as blocked records. The DMA 
transfer requires negligible amount of time, and simulates the 
Reinote Interface Unit (RIU) that will be used onboard the space- 
craft. This information supersedes the description of data, trans- 
mission given in the previous letter of August 20, 1981, and will be 
documented in greater detail in a question to the ATR. 

S.. Sanders gave the following information in response to CSC ques- 
tions: 

• Aritlimetic exception (divide by zero) will produce an inter- 
rupt. The operating system will then pass control to an error 
handling task in AADS. 
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• Addressing protection is available if an invalid address 
beyond available memory space is generated, but addressing 
protection is not available for individual tasks; a task 
can still write in the memory space of another task. Again, 
in the event of an addressing error, the operating system 
will pass control to an error handling task. 

'• The current VAX clock produces a timer interrupt once every 
10 milliseconds. This does not provide sufficient accuracy 
for gyro data and star camera data processing requirements. 
GSFC is considering buying a 1 millisecond clock. 

• The Intel will have 224 kilobytes of random access memory 
(RAM), and 16 kilobytes of read only memory (ROM) . Thus, 

AADS does not have the full 256 kilobyte memory as was 
specified previously for the Intel. 

C. Shenitz reviewed the design’ for the input and output tasks and 
described formats for ephemeris request and error messages. 

L. Jun, M. Stark, and R. Shwenk briefly reviewed the status of var-* 
ious subsystems in the AADS simulator. Onboard support system 
(OSS) will send requested ephemeris to AADS via the VAX mailbox 
facility. The format of the ephemeris table was defined by the 
attendees . 
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Yours truly. 



Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 


CSC 

S . Cheuvront 
G. Page 
K. Liu 
C. Shenitz 
G. Klitsch 
y. Frenkel 
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National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E-225 
and 

Mr. F. Snow 
Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS- 524 3 00 

Task Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow; 

This n;cmcrandum summarizes CSC's understanding of the topics die- 
cussed ar a meeting held on August 28, 1551, at GSFC to review 
task status. Present were L. Jun, R. Shwenk, F. Snow, M. Stark, 
and K. Tasaki of GSFC; S. Sanders of Systex; Y. Frenkel, G. Klitsch, 
K. Liu, K. Saralkar, and C. Shenitz of CSC. 

K. Tasaki discussed the procedure for starting AADS simulation. A 
Simulation tape containing gyro and star tracker data will be pre- 
pared by using the Landsat-D Simulator. Predicted attitude infor- 
mation will be stored on the tape along with data. The tape header 
will contain values for simulation control variables (orbital ele- 
ments, biases, misalignments, etc.). AADS will be loaded into the 
Intel memory, and the Intel clock will be initialized v/ith the sim- 
ulation time. The Sensor Data Simulator (SDS) will be invoked and 
start transmitting gyro data to AADS. At this point, there are 
several ways of synchronizing the activities of AADS and the AADS 
simulator tasks. The detailed startup procedure and synchroniza- 
tion will be documented in question number EXO 16. 
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S. Sanders reviewed the services available through the Intel 
operating system and gave the following information in response 
to questions posed by the design team: 

• A new operating system will be developed for the Intel 
because the Intel RMX operating system provides services 
which are somewhat different from those provided by the 
VAX/VMS operating system. Some portions of AADS will 
have to be redesigned to test AADS in the Intel-VAX sys- 
tem configuration if the old Intel operating system is 
used. 

• S. Sanders will distribute a list of operating system ser- 
vices to the design team. These services should be avail- 
able to AADS through the new operating system being devel- 
oped by Systex. 

o The mathematical subroutine library can be shared among all 
tasks if the library routines use a stack to store inter- 
mediate calculations. However, if the library routines use 
a fixed area in memory, then each task must have a separate 
copy of the mathematical subroutine library. Further de- 
tails about the library and a link procedure that will be 
used to link the AADS tasks will be documented in question 
number EX017. 

• Uplink and downlink messages csn he longer than bytes. 

Yours truly , 

Dr. K. SaraH^r 

Task Leader 

Attitude Systems Development 
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September 8, 1981 

TO: Distribution 

FROM: 582.1/Systems Development and Analysis Branch 

SUBJECT: Results from the Autonomous Attitude Determination System (AAOS) 
Critical Design Review 


A critical design review (CDR) of Autonomous Attitude Determination System 
(AADS), which included both the proposed onboard attitude system and the support 
simulator, was held on Tuesday, September 1, 1981. The presentation of the 
review material was shared by the following persons: 


Introduction 

K. 

Tasaki/GSFC/582.1 

Design of Ground Support Subsystem 

M. 

Stark/GSFC/582.1 

Design of Onboard Support Subsystem 

L. 

Jun/GSFC/582.1 

Design of Sensor Data Subsystem 

R. 

Schwenk/GSFC/582.1 

Design of System Software 

S. 

Sanders/SYSTEX. Inc. 

AADS Overview 

K. 

Saralkar/CSC/Task 924 

Design of AADS Executive 

G. 

Klitsch/CSC/Task 924 

Design of I/O Subsystem 

c. 

Shenitz/CSC/Task 924 

Overview of Mathematical Modules 

K. 

Liu/CSC/Task 924 

Development Schedule 

K. 

Tasaki/GSFC/582.1 


This CDR was primarily to cover the AADS Executive and the AADS I/O subsystem 
for which the detailed design has been completed. The CDR for the attitude 
propagation/determination modules has been scheduled tentatively for November 3, 
1981. The design of the three subsystems for the AADS simulator was also 
presented along with the description of the required system support software. 

The following points and action items were noted during and after the CDR: 

1. The Landsat data tape format design by R. Schwenk will be presented to 
the Landsat Simulator task personnel for their comments since they will be 
providing the data tape to the AADS simulator group. Arrangements will be 
made between the two groups for the generation of data tapes after the 
contents and the format are finalized. 

Action Item: R. Schwenk and K. Tasaki will meet with the Landsat simulation 
group within a week to begin discussion. 
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2. The function of the remote interface unit (RIU) needs to be better understood 
since the raw gyro and star tracker data are made available to the rest of the 
S/C via this piece of hardware. In particular, the bit patterns and the field 
definitions for the two sensor data types, the operating characteristics , the 
delay between the time of observation and the arrival time of the data in RIU, 
and other relevant information must be known in order to accurately simulate 
this device. 

Action Item: F. Snow will obtain the information within 2 weeks. 

3. The simulation of uplinking and downlinking of AADS code was eliminated from 
the original set of requirements. To simulate the downlinking of AADS code and 
data areas (memory dump) can be done without much difficulty. However, the simu- 
lation of uplinking the code via the AADS simulator is another matter. It is very 
mission-dependent, i.e., we have to know the boot-strap procedure of the onboard 
processor into which AADS is to be loaded. The boot program, which must reside in 
ROM, must be a specialized program to recognize AADS message format and protocols. 
For this reason, it is proposed that only the memory dump capability be implemented. 

Action Item: K. Tasaki will further investigate the feasibility with the 

Task 924 personnel and accordingly modify the requirements and the design. 

4. As stated on page 1-33 of the CDR review material, all intertask communication 
will be via global COMMON, and the SEND/RECEIVE type of system services will not 
be used. In addition. Task 924 personnel will examine the list of system services 
routines proposed by SYSTEX for INTEL operating system implementation. 

Action Item: K. Saralkar will examine and reduce the number of the system 

services routine by September 30, 1981. 

5. A comment was made concerning the possibility of having a software clock to 
synchronize the timing among all Processes and to control the simulation, i.e., 
eliminating the dead time, slowing down the simulation when desired, etc. During 
the PDR held on February 23, 1981, a point was made that the final AADS must be 
demonstrated in real time. With 50 and 64 millisecond cycle times for the star 
tracker data and the gyro data, respectively, the elimination of any dead time 
within these cycles will lock the VAX CPU disabling any other user on the VAX 

to execute his program. It is envisioned that stand-alone times on the VAX will 
not be allowed. For these reasons, the feature to eliminate dead times will not 
be incorporated into AADS. For a long simulation case, i.e., a few days, AADS 
and the simulator can be set up to run several hours at a time introducing the 
last computed attitude as input at the time of restart. 


6. There are a number of ways to implement the Kalman filter, i.e., the Joseph 
form, the UDUT, the standard approach, etc., primarily to minimize the execution 
time while retaining sufficient accuracy and stability. A choice should be made 
soon so that there will be no impact on the software design. 


Action Item: F. Snow and E. Lefferts Will make the decision with C. Shenitz 

and K. Liu of Task 924 on the choice of filter implementation by September 30, 



Concurrence 
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September 9/1981 


National Aeronautics and Space Administration. 
Goddard Space Plight Center 
Greenbelt, Maryland 20771 


/Attention i 


Sub joe L- : 


Mr^ K. Tasaki 
Cods 501.2 

Bldg. 2,3/ Room E-225 
and 

Mr. F. Snow 
Code 582.3 

Bldg. 23, Room E-239 

Contact NAS" 524300 
Task Assignmeiit 92400 

Autonomous Attitude DeterTnination, System (AA.DS) 
Critical Design Reviev/, September l", 1981 


Dear Messrs. Tasnki and R.nov/: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at the Critical Design Review (CDR) ?)eld on September 1, 1981, 
at GSx'C. P3:esent were A. Fuchs, L, Jun, E . i Lefferts , ~ R. Shv/enk , 

P. S 210 V/, M. Stark, K. Tasaki, and R. Working of GSFC; S. Sanders 
of Systex; and Brovm, V. Church, Y. Frenkel, G. Klitsch, K. Liu, 

G. Page, E. Saralkar, and C. Shenitz of CSC. 

K. Tasaki gave an overview of AADS and the/AADS simu.Iator, and pre- 
.sonted a schedule for completing development and testing of AADS 
and related software. M. Stark, L. Jun, and R. Shv/enk pre.sented, 
respectively, the ground support .simulator (GSS) , the onboard sup- 
port simulator (OSS), and the sensor data simulator (SDS) . 

S. Sanders presented the Intel operating systera (Intel/OS) , and 
described the In tel development system and the Intel-VAX svstem 
configuration _ that will be used during AADS tes.ting; K. Saralkar 
gave an overviev/ of AADS; K. Liu rev’iewed, the top"level desi.gn for 
the attitude computation function; G. Klitsch reviev;ed the execu- 
tive task and described scheduling logic; and C. Shenitz roviev/ed 
the input, output, and sensor data coilection tasks. 
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No major chrmges v’ill bo required to the current 7iADS design as a 
re.sult of the CPR; however, several questions were raised during 
the discussion, peurti cularly about the i nterfaces betv/een the var- 
ious simulator tasks and A/\DS. A summciry of these questions is 
given be lov,'. Some of these questions will be documented in ques- 
tions to tJie ATRs. 

o The Landsat-D simulator currently being developed by CSC 
(Task 91100) will be used to provide test data for AADS. 

o GSFC personnel V'?!!! investigate the hardware specification 
•for the gyro and star cameras used for the Landsat-D simu- 
lator. GSFC personnel v;ill also investigate the hardWcire 
specifications for the Remote Interface Unit (RIU) and ob- 
tain n'loro information about sensor data collection and trans- 
mission onboard the spacecraft. 

o GSFC personnel w»ill investigate the capabilities and sx-'jocifi^ 
cations of the Landsat-D simulator with respect to sensor 
data format, i^redicted attitude, observed star information, 
and header information containing the simulation options. 

o AADS V7ill require several days (greater than 3) of contin- 
uous simulation data. GSFC personnel v/ill determine \7hecher 
the Landsat-D simulator can support data siDans that long. 

e The Landsat-D simulator does nut ^simuJate of the 

fiold-of-view for new stars, a b.rt in the star camera aara 
indicates star presence. The design team v.’ill obtain the 
complete format of star camera datci to detorjriine’ w.hether the 
current design properly supports processing the data even 
when the star Ccimeras are turned off. 

© GSS will provide for checking the accuracy of AADS computa- 
tion and. star identification. A plot package will be needed 
in GSS to generate line printer plots of the comxjuted versus 
predicted (simulator)^ attitude. 

© GSFC personnel will determine if the Joseph form of the 

Kalman filter, which is s]pecified for state update in A7iDS, 
is suitable v;ith respect to execution time and roundoff 
error elimination. 

« The design team will investigate the possibility of using- 
a softv;are clock for JiADS and the AADS simulator. The 
softv;are clock will speed vip AADS testing, and will be par- 
ticularly useful for the long (3-to-4~day) test runs planned 
for AADS . 

G» AADS v/ill be stored in ranclom accass memory (R7\M) . Tho'. 
Intel/OS W'ill support upTink/dovmlink of AiADS in the event 
of R/U'i failure or for debugging purxjoses . The design team 
v/ill identify all such cax>obilitios required to maintain 
AADS onboard the spacecra.ft. 
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9 ThC: design team will detorraine the communications protocol 
boL'.v.'*on AadS ana the OBC, since the OP.C is expected to trans- 
mit data annotation results to the ground. 

o The Intel/OS will simulate the RIU by accepting the sensor 
data transmitted by SDS . Star data from alternate cameras 
will be avciilable at 50-raillisecond periods. These data 
will be stored in two separate locations in A/\DS memory by 
the Intel/OS. Gyro data v;ill be stored in a separate loca- 
tion every 64 milliseconds. The sensor data collection 
tc>sk in ZvADS will read gyro data once every 64 milliseconds 
and star data from both cameras once every 100 milliseconds. 

« It is expected that the RIU will also store sensor data in . 
2 ^DS memory at knovm intervals . Ho'wever, the sensors and 
data format are mission dependent. 

o A7\DS v;ill perform autonomously as long as the attitude error 
is small (less than 2 degrees) and spacecraft ephemeriS data 
are available from the OBC. AAD3 is currently designed to 
perform gyro propagation and data annotation at a minimum 
period of 512 milliseconds. 

Minor questions on occultation computation, maneuver handling, star 
catalog size and structure, pairv^ise and direct star matching tech- 
niques, and the capabilities of the Intel /OS were discussed. These 
will be documented as questions v/nerc appropriate. 

Yours truly, 


Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 
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National Aeronautics ancl Space Admiriist.ration 
Goddard Space Plight Center 
Greeiibelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E- 2 25 
and 

Mr . F . Snow 

Code 582.3 • 

Bldg. 23, Room E-239 

Subject: Contract NAS- 524 3 00 

Task Assignment 92400 

Autonoiiious 7ittitude Determination System (AADS) 

Follov/~on Task Assignment 


Docir Messrs. Tasaki and Snov/: 

Thin m e>iK> r a ndi iTn CSC?: ”.ncTer'’t*'.r;'f!irig of the ieciricns made 

at a laeating held on September 4, 1981, at GSPC to review cind clarify 
the requircniGnts for the microprocessor based auto noraous attitude 
determination system (ZntDS) . Present v;ere F. Snov; and K. Tasaki of 
GGPC; <and G. Page and K. Saralkar of CSC. The following decisions 
were made during the meeting: 

o Baseline diagrcuas, I/O definitions a.nd the process descrip- 
tions will be delivered, to the ATRs 1 week before the Criti- 
cal Design Reviev; for the attitude computation functicn. 
Subroutine prologs v.-ill be available on the VAX computer at 
this time, and can be obtained from tlie librarian upon re- 
quest. 

«s AIkDS testing v;ill be completed on the VAX computer by the end 
of the follow-on task period. Hcv/ever, the amount of testing 
in the Intel*-VA.X system configuration v/i 11 depend cn the avail- 
ability of the Intel operating system and other hardv;are re- 
quired for Intel-VAX testing. 

The new Intel operating system being developed for AADS by 
Systex will be compatible with the VAX/VMS operating system 
used during 7LADS development on the V/AX. In addition, the 
Intel FORTRAN/86 compiler is expected to be compatible v;ith 
VAX FORTRAN (Version 2 . 0) . Under these two assumptions, the 
conversion of IJiDS to the Intel siiouid be straightforward. 
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o GSC porGonnol recommend that the now Intel operciting system 
should be thoroughly tested by Systox personnel v/ith the 
7v7vDS skeleton as early as possible to uncover any interface 
problems v:ith the AADS executive. AA^DS testing in the Intel- 
VAX systeni configuration could be severely impacted if any 
interfctce problems remain at this point. 

.o The final system description document v/ill include sections 
on 1) system overview, 2) requirements and specifications 
summary, 3) descriptions for all control variables in global 
COMlsOP areas, 4) system execution and computer resources, 

5) baseline diagrams and processing overviews for all tasks, 

6) basic algorithms, and 7) subroutine prologs . This docu- 
ment v;ill evolve from the design document that wa.s prepared 
under Task 92400, Section 2 v;ill be completed by incorpor- 
ating information from all task letters and answers to the 
questions. Section 2 v;ill have a .subsection on changed and 
nfcw requirements. Sections 3, 5, 6, and 7 are mainly complete 
at this stage and v^ill be modified as required during the de- 
sign of the attitude computation function. Section 4 v/ill 
describe file structure and coramands necessary for system 
generation and execution, 

9 CSC personnel will prepare a system task plan for the testing 
of AADS.- T’be ta-st plan v.all have a detailed description of 
tesr. data, procedures to run the tests, and the expected re- 
suits. Test evaluations V 7 ill compare the actual results wren 
the expected results. The final evaluation report document 
will be piepared by adding the test reports to the system 
test plan* The AADS systera test plan will be similar to the 
acceptance test plans prepared for the Dynamics-B Explorer 
Attitude Determination System, but the precise format of this 
document will be defined later. 

« GSFC personnel v/ill prepa.re a user ' s guide for A.ADS . This 
guide v/ill be V7ritten for both the sy.stem operator and the 
system analyst. CSC v;ill provide material on the use of the 
filter that is used to update the state vector. 


lours truly. 



Task Leader 

Attitude Systems Development 

KS:gsp 
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October 1, 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mt. Tasaki 

Code 581.2 
Bldg. 23, Room E-225 

and 

Mr. F. Snow 
Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS-524300 

't'ask Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs, Tasaki and Snow: 

This memorandum summarizes CSC ’s understanding of the topics discussed 
at a meeting held on September 18, 1981, at GSFC to review task status. 
Present were K. Tasaki of GSFC; and G. Klitsch, K. Saralkar, and 
C, Shenitz of CSC. 

The attendees discussed system test procedures including the startup 
scenario and specific build 1 capabilities to be tested during the 
initial period. The following decisions were made during the meeting: 

e Sensor Data Simulator (SDS) will be activated a short time before 
AADS is started. This will simulate the actual onboard condi- 
tions . 

• Task scheduling and the interfaces between AADS and the AADS 
simulator will be tested in build 1 testing. 

• Landsat-D simulator data will be available on or before 
November 18, 1981. Therefore, SDS will send dummy data to AADS 
to verify the interface between SDS and AADS. 

• R. Shwenk will study the softvrare clock design proposed by 
C. Shenitz to determine the impact on the SDS. 
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• The design team will examine the need for a restart capability 


Yours truly. 



Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 


KS:gsp 

copies: GSFC CSC 


F. McGarry S. Cheuvront 

E. Lefferts G. Page 

A. Fuchs K. Liu 

C. Shenitz 
G. Klitsch 
y. Frenkel 



C-33 



COMPUTE3R SCIENCSS CORPORATION 

SYSTEM SCIENCES DIVISION ( 3 (_r 1) 5 ti - 1 b -i 5 

8728 COLESVILLE ROAD • SILVER SPRING. MARYLAND 20910 

October 1, 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 
Bldg. 23, Room E-225 

and 

Mr . F . Snow ■ ^ 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS-524300 

Task Assignment 92400 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at a meeting held on September 25, 1981, at GSFC to review 
task status. Present were L. Jun, F. McGarry, R. Shwenk, F. Snow, 

M. Stark, and K. Tasaki of GSFC; S. Sanders of Systex; and Y. Frenkel, 
G. Klitsch, K. Liu, K. Saralkar, and C. Shenitz of CSC. 

S. Sanders reviewed the status of the Intel system software. He 
reported that the mathematical subroutine library requires approxi- 
mately 2.5 kilobytes of memory, and it can be shared by all tasks^ 
in AADS. The attendees then reviewed the FORTRAN source to verify 
interfaces between AADS and the AADS simulator. 

The following points were noted during the discussion that followed; 

• The Sensor Data Simulator (SDS) will write gyro and star 
tracker data to a mailbox. SDS will then write the contents 
of the mailbox to a global COMMON accessible to the sensor 
data read task in AADS. A system routine will write the con- 
tents of the mailbox to a specific Intel memory location in the 
Intel version of the software. 

• The star data times will be in error by 50 milliseconds (maxi- 
mum) , because the data are read every 50 milliseconds . ^ A sig- 
nal is available onboard which indicates how much time has 
elapsed since the data were accessed by the Remote Interface 
Unit (RIU) . F. Snow will obtain more details about this sig- 
nal. 
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• The ephemeris request from AADS to the Onboard Support System 
(OSS) will contain the start time for the ephemeris in sec- 
onds since September 1, 1957, 0 hours UT. The ephemeris in- 
terval will be given in seconds. OSS will return the space- 
era ft- to- Earth vector in kilometers, and the spacecraft 
velocity relative to the Earth in kilometers/second. 


• The design team recommends that AADS should be tested using 
a 4-day data segment to verify the autonomy goal. However, 
the actual requirement may have to be set lower because long 
spans of data may not be available. F. Snow will determine 
• the autonomy requirement. 


Yours truly, 


Dr. K. Saralkar 
Task Leader 

Attitude Systems Development 


KS ; gsp 

copies : GSFC GSC 


F. McGarry 
E. Lefferts 
A. Fuchs 


S . Cheuvront 
G. Page 
K. Liu 
C. Shenitz 
G. Klitsch 
Y. Frenkel 


ORIGINAL PAGE is 
OF POOR QUAUTV 


COMPUTER SCIENCES CORPORATION 

SYSTEM SCIENCES DIVISION i .3 O ‘ ! 5 8 3 ’ 5 5 

8- 8 a C0i-£;3VILLC 80 AO • S ( L V E R 3 P 8 i \ G . M A 8 L A \j O 2 O 3 ' C 

October 5, 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 
Bldg. 23, Room E-225 

and 

Mr. F. Snow 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS-524300 

Task Assignment 94200 

Autonomous Attitude Determination System (AADS) 

Dear Messrs . Tasaki and Snow; 

This memorandum summarizes CSC’s understanding of the topics dis- 
cussed at a meeting held on October 2, 1981, at GSFC to review task 
status. Present were L. Jun, R. Shwenk, F. Snow, M. Stark, and 
K, Tasaki of GSFC; S. Sanders of Systex, and Y. Frenkel, G. Klitsch, 
K. Liu, and K. Saralkar of CSC. The following points were noted 
during the meeting: 

• The design team will prepare a configuration control plan 
that will protect the source and task images, control the . 
implementation of new capabilities, eliminate errors, and 
provide a mechanismt for reporting the status of system test- 
ing to the ATRs and to GSFC and CSC management. 

• The design team will prepare Digital Command Language (DCL) 
procedures to initiate AADS and the AADS Simulator and to 
create task images. 

• K. Tasaki will determine a procedure for downlinking/uplinking 
an AADS image to the Intel memory during a mission. 

• The design team will study the procedure to uplink processing 
options to AADS. 

• CSC personnel delivered a list of the required Intel operating 
system services to the ATR. Some previously specified system 
services were eliminated and several other system services 
will be replaced with stubs to reduce coding changes in the 
Intel version of AADS. 
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• There are some differences between VAX- 11 FORTRAN and Intel 
FORTRAN, K. Tasaki will provide the available Intel FORTRAN 
documentation to CSC personnel. Task members will use the 
Intel FORTRAN conventions as far as possible. 
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National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E-225 
and 

Mr. F. Snow 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS 5-24300 

Task Assignment 94200 

Autonomous Attitude Determination System (AADS) 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at a meeting held on October 7, 1981, at GSFC to reviev/ task 
status. Present were L. Jun, F. McGarry, M. Stark, and K. Tasaki 
of GSFC; S. Sanders of Systex; and G. Klitsch, K. Saralkar, and 
C. Shenitz of CSC. The following points were noted during the meet- 
ing: 

• In the Intel version of AADS, sensor data are made available 
to AADS using Direct Memory Access (DMA). Gyro and star 
tracker data are written to a specified area in AADS memory 
and then read by the sensor data read task. It is possible 
tiiat some data may be lost if the DMA write and subsequent 
read functions are not synchronized. The problem could be 
eliminated by disabling the DMA write while the data written 
earlier is being read by AADS. The attendees agreed that 
more information is needed about the sensor data collection 
function of the Remote Interface Unit (RIU) onboard the space- 
craft before any particular hardware or software model of the 
RIU is selected, 

• The ATRs will review and then provide comments on the outlines 
provided by CSC for the AADS system description manual, the 
system test plan and evaluation report, and the configuration 
control procedures. 
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• The ATRs will provide input toward selecting the test data 
sets to be used during system testing. Ten separate tests 
and data sets will be defined for VAX system testing. The 
same tests and data sets will be used for testing the Intel 
version of AADS. 

• CSC will prepare a short, informal test summary after system 
testing of each of the 4 builds on the VAX. 

• COMMON/ STATIC/ contains all variables that control AADS proc- 
essing. F. Snow will review the descriptions of these vari- 
ables (VAX file {AADS. GDSTATIC. FOR) and determine the cor- 
rectness of the variable definitions. 

• K. Saralkar will decompose COMMON/STATIC/ into 4 separate 
COMMON areas so that a single category of control variables' 
(e.g. task schedules and priorities) can be uplinked to AADS 
independently of other control options. 

• There are some differences between the VAX and Intel internal 
representations for numeric data. The Ground Support System 
(GSS) will convert data to the Intel format before uplinking, 
and convert the Intel output to the VAX format. The Sensor 
Data System (SDS) will convert . sensor data to the Intel for- 
mat before transmitting the data to AADS. This procedure will 
be used when AADS is implemented on the Intel microcomputer. 

Yours truly. 



Or. K. Saralkar 
Task Leader 

Attitude Systems Development 
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National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr^. K. Tasaki 

Code 581.2 
Bldg. 23, Room E-225 

and 

Mr. P. Snow 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS 5-24300 

Task Assignment 94200 

Autonomous Attitude Determination System (AADS) 
pear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topics dis- 
cussed at two separate meetings held on October 14, 1981, at GSFC 
to review task status and star identification methods, respectively. 

Present at the first meeting were L. Jun, R. Shwenk, M. Stark, and 
K. Tasaki of GSFC; S. Sanders of Systex; and Y. Frenkel, G. Klitsch, 
and K. Saralkar of CSC. The following points were noted during this 
meeting; 

• S. Sanders discussed the software development procedure on the 
Intel development system. This procedure will be documented in 
a question to the ATRs. 

• K. Saralkar noted that the Intel FORTRAN manual does not de- 
scribe the DOWHILE construct. This construct is available in 
the VAX FORTRAN, and is used extensively in the AADS code. 

K. Tasaki will determine whether the DOWHILE construct is 
available in the Intel FORTRAN. 

• K. Tasaki described a preliminary version of the Digital Com- 

mand Language (DCL) procedure that will be used to initiate an 
AADS simulation. At least two terminals will be needed during 
the simulation. G. Klitsch will provide to K. Tasaki the fol- 
lowing information about AADS: 1) process priorities, 2) param- 

eters needed to run the processes, 3) files opened. 
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• M* Stark described the difference between VAX and Intel in- 
ternal numeric data formats. The attendees agreed that the 
Intel version of AADS will not send a negative floating point 
zero to the Onboard Support System (OSS) on the VAX, because 
the VAX treats that particular bit pattern as an error. 

Ground Support System (GSS) and OSS will perform other required 
conversions before transmitting or receiving data from AADS. 


Present during the second meeting were E. Lefferts, F. Snow, and 
K. Tasaki of GSFC; Y. Frenkel, G. Klitsch, K. Liu, and K. Saralkar 
of CSC. K. Liu described the star identification method used by 
AADS, and also described a triplet matching algorithm used by the 
Solar Maximum Mission Attitude Determination System (SMM/ADS) . The 
attendees agreed that the modified pairwise matching scheme used in 
the current design is adequate. This modified pairwise matching 
scheme and other questions raised during the meeting will be docu- 
mented in questions to the ATRs. 

Yours truly. 
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National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention: Mr. K. Tasaki 

Code 581.2 

Bldg. 23, Room E**225 
and 

Mr, F. Snow 

Code 582.3 

Bldg. 23, Room E-239 

Subject: Contract NAS 5-24300 

Task Assignment 94200 
Autonomous Attitude Determination 
System (AADS) 

bear Messrs. Tasaki and Snow: 

This memorandum summarizes GSC's understanding of the topics dis- 
cussed at two separate meetings held on October 21, 1981, at GSFC 
to reviev/ attitude determination function design, and AADS system 
testing, respectively. 

Present at the first meeting were E. Lefferts, R. Shwenk, F. Snow, 
and K. Tasaki of GSFC; Y. Frenkel, G. Klitsch, K. Liu, and K. Saralkar 
of C®C. The following points were noted during this meeting; 

• In. response to a question from CSC, the ATRs replied that 
the section 5 (AADS Algorithms) of the AADS system descrip- 
tion document will contain the state propagation and update 
analysis done by E. Lefferts for AADS. The ATRs have not 
specified any other material for inclusion in section 5. 

• E. Lefferts described the computation of attitude uncer- 
tainty. In the small angle approximation, the diagonal 
elements of the covariance matrix are the squares of 
rotational angles . Either the squareroot of the sum of 
diagonal elements, or the squareroot of the largest diagonal 
element can be used as a rough measure of the attitude 
uncertainty . 
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• K. Liu described the star identification procedure. AADS 
will compute the attitude uncertainty E, and the window 
size for accessing catalog stars, N*E. N is nominally 
set to 4 or 5, and can be changed by a ground command. 

When the attitude is known accurately, the attitude uncer- 
tainty, and therefore, the window size is small. The 
window around an observed star will contain a single can- 
didate star, and direct star identification is used. When 
attitude uncertainty is large, the window size is also 
large. It is possible that several cancicates may be found 
for a single observation, and pairwise matching is used for 
star identification. 

0 Current AADS design uses doi:iblet stars for star identifica* 
tion. F. Snow will determine if doublet stars should be 
discarded, 

0 AADS will calculate the star magnitude from the calibrated 
star intensity. This magnitude will be compared with the 
visible star magnitude stored in the AADS star catalog. 

0 AADS will rotate track point unit vectors to the GCI frame 
using gyro propagated attitiides . The track point unit 
•vectors in the GCI frame will be then averaged to form a 
sinqle observation unit vector per star. 

0 AADS will use the regular form of the Kalman filter for 
state propagation and update. The filter will be imple- 
mented using a standard recursive algorithm in which the 
identified stars are processed one at a time. The state 
covariance matrix will be renormalized after every update. 
E. Lefferts indicated that the diagonal elements of the 
covariance matrix will not become zero or negative 
during the computation, but the covariance matrix may 
lose its symmetric form. The logic for correcting this 
condition will be added to the design. 

0 Gyro saturation check will be removed from •the sensor data 
collection (SENS IN) task, and will be done in the gyro 
data processing (GYPROC) task. Successive points v/ill 
be used to check for saturation; end points will be used 
for rate computation. The system executive will schedule 
an immediate update when the gyro saturation condition 
is reported by the GYPROC task, 

0 Spacecraft maneuvers may start and end in the middle of 
a span of data being processed by the GYPROC and PROPAG 
tasks. In this case, the data will be processed sepa- 
rately to perform state propagation. 
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Present during the second meeting were L. Jun, R. Shv;enk, M. Starke 
and K. Tasaki of GSFC; Y. Frenkel, G. Klitsch, and K. Saralkar of 
CSC. In response to a request by K. Tasaki, G. Klitsch delivered 
a list of priorities and system resources for all tasks in AADS. 

M. Stark and K. Saralkar reviewed the formats |!or the various re-" 
ports transmitted by AADS. The attendees discussed AADS system 
testing completed during the week and planned future test sessions. 
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Yours truly. 


Dr. K. Saralkar 
Task Leader 

Attitude System Development 


GSFC CSC 

F. McGarry S. Cheuvront 

E. Lefferts G. Page 

A, Fuchs S. Waligora 

K. Liu 
C. Shenmz 
G. Klitsch 
y. Frenkel 




SYSTEM SCIENCES DIVISION <301) 589-154 5 

8728 COLESVILLE ROAD • SILVER SPRING, MARYLAND 20910 


November 11, 1981 


National Aeronautics and Space Administration 
Goddard Space Flight Center 
Greenbelt, Maryland 20771 

Attention; Mr, K. Tasaki 
Code 581.2 

Bldg, 23, Room E*-225 
and 

Mr, F. Snow 
Code 582,3 

Bldg, 23, Room E-239 

Siibject: Contract NAS 5-24300 

Task Assignment 94200 

Autonomous Attitude Determination System (AADS) 

Critical Design Review, November 3, 1981 

Dear Messrs. Tasaki and Snow: 

This memorandum summarizes CSC's understanding of the topis discussed 
at the Critical Design Review (CDR) held on November 3, 1981, at GSFC. 

Present were A, Fuchs, L. Jun, E. Lefferts, F. McGarry, R. Shwenk, 

F, Snow, and K, Tasaki of GSFC; Y, Frenkel, G. Klitsch, K. Liu, G. Page, 

K. Saralkar, C. Shenitz, and S. Waligora of CSC. The design team pre- 

sented the detailed design for the attitude determination function in 
AADS, the top level design for which had been presented at an eariler 
CDR held during the previous task period (Task 92400) . 

K. Saralkar described the purpose of the CDR and detailed the agenda 
for the meeting. He then gave a brief overview of AADS, described 
the major changes in AADS requirements, and current task status. 

Y. Frenkel presented the design for the gyro data processing (GYPROC) 
and gyro propagation (PROPAG) tasks. K. Liu presented the design for 
the star data processing (STRACK) , star identification (STARID), 
and state update (UPDATE) tasks. Y. Frenkel presented the design for 
a utility which creates an AADS star catalog from the main SKYMAP 
star catalog. Finally, K. Tasaki discussed the system testing con- 
ducted for a skeleton AADS system (which includes the executive and 
input/output functions) , and K. Tasaki and K. Saralkar summarized 
the results of the CDR. 
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Following points were noted during the meeting for appropriate 
future action by the design team: 

• £. Lefferts expressed a concern about the lengthy calculations 
being performed during state propagation and update. He sug- 
gested that the AADS performance can be improved by bypassing 
some relatively unimportant calculations, and using approx- 
imations and/or alternative formulations where possible. 

K. Saralkar replied that the predevelopraent timing estimates 
show that AADS can perform all required calculations in approx 
imately half the available time even for the worst case sce- 
nario. Therefore, all attitude determination algorithms were 
implemented in a simple and direct manner without any attempt 
at time optimization. Time and/or memory optimization will 
be performed later, if required in light of the knowledge 
gained during the actual testing of AADS. 

• In the current design, gyro data is processed nominally every 
512 milliseconds; however, state vector and covariance matrix 
propagation is performed after N gyro data processing inter- 
vals Here the value of N is nominally equal to 1, but can 
be optionally set to a higher integral value. E. Lefferts 
suggcsLed that in order to save cumputational Lime, covariance 
matrix propagation should be separated from state propagation, 
and should be performed at a lower frequency. That is, the 
covariance matrix should be propagated after the state vector 
is propagated M times , where M may be typically set equal to 
100. The design team will reviev; this requirement and will 
outline the necessary design change. The design change will 
be implemented during build 3 if it is approved by the ATRs. 

• E. Lefferts raised additional questions about the implemen- 
tation of the propagation algorithm and the use of the re- 
cursive filter for state update. Y. Frenkel and K. Liu will 
describe in detail the specific equations, numerical approx- 
imations, etc, used for attitude determination , and submit 
this handwritten material to the ATRs for approval. 

• In response to a question from K. Tasaki, K. Liu described 
the procedure for computing average star vectors. In the 
current design, all star observations for a single observed 
star are transformed to a geocentric inertial (GCI) frame, 
and then averaged. A rotation matrix computed from the atti- 
tude quarternions is used for this transformation. In an 
alternate scheme, the previously averaged star vector 

is transformed to the current tracker frame using a small 
angle rotation matrix and averaged with the current star vec- 
tor. The resulting average vector is finally transformed to 
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the GCI frame. These two procedures are mathematically 
equivalent. The second procedure may be slightly faster as 
compared to the first procedure, but is more complex. 

• AADS computes a window size from the current attitude uncer- 
tainty (and appropriate multiplication factor) to select 
candidate stars in the vicinity of the observed star. Thus, 
the Window is coupled to the attitude uncertainty, obviating 
any need for automatically expanding the window when there 
are no candidate stars in the window. This condition (no 
candidate stars) implies that the initial attitude estimate 
may be in error by a large amount, and it must be corrected 
by a ground command. 

Yours truly. 

Dr. K. Saralkar 

Task Leader 

Attitude Syst ojrts lopment 

KS/stb 

Copies: GSFC 

F. McGarry 
E. Lefferts 
A. Fuchs 
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G . Page 
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K. Liu 
C, Shenitz 
G. Klitsch 
Y. Frenkel 
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November 12, 1981 


TO: Distribution 


FROM: 582.1/Systems Development and Analysis Branch 

SUBJECT: Results of the Critical Design Review (CDR) of Mathematical Modules 

for the Autonomous Attitude Determination System (AADS) 


A critical design review (CDR) of the mathematical modules for the 
Autonomous Attitude Determination System (AADS) was held on Tuesday, 
November 3, 1981. The primary purpose of this CDR was to review 
the detailed software design of the following modules: the gyro data 

processing, quaternion and state covariance propagation, star tracker 
data processing, star identification, and state update. The presentation 
of the review material was shared by the following persons: 


Overview 

Gyro data and propagation 
Star identification and update 
Star catalog management 
Design consideration 
Schedule 


K. Saralkar/CSC/Task 942 
Y. Frenkel/CSC/Task 942 
K. Liu/CSC/Task 942 
Y. Frenkel/CSC/Task 942 
K. Saralkar/CSC 
K. Tasaki/GSFC/582.1 


Only one major design problem was uncovered during the CDR. E. Lefferts noted 
that there should be a separate frequency for the covariance propagation which 
is different from the state propagation frequency. Since the covariance 
matrix need not be propagated as’ frequently as the attitude state, by 
providing a separate frequency as another input parameter, the computational 
time for this function can be significantly reduced. As an action item. 

Task 942 will assess the impact of this change to the current subprocess 
scheduling logic, as well as to any existing design and/or software by 
November 18i 1981. All decisions concerning the implementation of this change 
will be made after the review of the impact assessment. 
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